Programming fun at startup

I hate last minute fixes and especially on things that I dont understand much. Today is release day and I was called by my product manager friend about some bug that I had no clue what that feature was. With some help from product manager I was able to reproduce the issue locally and 90% of the problem is solved when you can reproduce the issue. So it took 30 min to fix it as it was an easy fix.  It took more time to merge the damn fix. The reason was that developer had totally different packages in release and trunk and also in trunk there were many private interface changes. The bug has been there for 2 weeks in production so why was it detected after 2 weeks. Two reasons: 1) This was some custom feature developed for only this customer. I hate these WTF custom feature. 2) Well it seems the customer already knew about the bug and Professional services schedules calls on Friday and Friday night is our release so customer waited a week to tell us. Nothing can be done about cu

We use jfileupload applet in our cloud server to allow users to upload folder hierarchy from browser. Recently our security team found an issue that if our site was vulnerable to XSS then anyone can read the jsessionid cookie.  To fix this I changed the tomcat server.xml context attribute useHttpOnly="true" and most of the things were fine but the applet broke. now it was giving me nothing except "unable to load" and NullPointerException string (no stacktrace) in applet console.  I first thought its some local issue but then  I tried from multiple machines and same issue. Googling didnt helped. Finally after spending 3-4 hours I found that when applet tries to download the jar files the request were coming to tomcat and we were applying a WebSessionFilter that would redirect requests with no sessions to login page. Skipping .jar files download from session filter  check solved the issue.  (I know, I know we should have used apache to serve the jar files and

I need to chase this but when I ran memcached-top command on our prod boxes I saw we had 1:20 read vs write ratio. INSTANCE USAGE HIT % CONN TIME EVICT READ WRITE memcache01:12345 85.8% 94.7% 4039 1.1ms 1.5M 4.3T 80.9T memcache02:12345 85.8% 93.4% 4022 1.2ms 1.6M 4.7T 80.5T This is throwing me off. I will analyze to see what i causing it because we should technically see more reads and less writes.

My colleague made an interesting command that AOP is like a drug and once you have tasted it you can spot cross cutting concerns and the mere presence of duplicate code tells you the signs of martin's fowler's bad smell in code.   We use jersey to implement rest apis and our rest apis can be called from Session or BasicAuth or Oauth, after a user is successfully authenticated we inject the caller user object in request as an attribute so the rest api can derive it to further make api level business validation.  But that means every api method has to write this ugly piece of code where we inject request into the signature and then add this one line of code to get the user object.       public Response getDevicesForCustomer(@Context HttpServletRequest request, ....) {         User user = (User) request.getAttribute("user"); ... } This sounds like a perfect cross cutting concern to be baked into AOP layer. What would be nice if we could do it like this     publ