This morning I noticed that Google Chrome dev 26.0.1410.10 was released with another very respectable set of release notes. Sounds like a lot of little fixes, but necessary and advancing the cause of a better browser. I have to say I haven't seen a regression in the rendering or speed in a very long time.
Nice work, Googlers.
This morning I noticed that Apple had a Java 1.6 update for the Java exploit that's been going around, and Oracle had another for 1.7. It's interesting how vulnerable Java is these days - maybe because the other, historically more likely, back-door (open ports on boxes), has dried up of late. So the jerks turn to Java, and find problems and exploits there.
Seems reasonable to stay up to date because some Facebook and Apple engineers have had their machines compromised by visiting a hacked web site. Amazing that they can do this from visiting a website, but that makes sense in the context of Java plugins.
Crazy what poorly written software combined with kids with too much time on their hands can lead to. Kinda annoying…
Well… I've really held off about as long as I can, and even then, it's probably a bit too long for what I'm doing. This morning I downloaded the Oracle JDK 1.7.0_13 with the latest security fixes for my main laptop. This is a big switch as I'd been holding out for Apple to step back in and really do Java right, but I think they are past that now, and it's up to Oracle to make Java work on Macs, and I pray that they do.
I'm doing more clojure coding, and with that, I really need to have the 1.7 JDK underneath, as there are optimizations that are done in the compiling if it's on the 1.7 platform. Since we're using that on the linux boxes at The Shop, and I have 1.7 on my work laptop, it makes sense to give it up, and switch.
I guess it's like my 17" MacBook Pro… legacy hardware. I'll move to the 15" with retina display for my next machine, and it's a beauty, and it's nice that it's smaller and lighter with the same pixel count, so it's a win - really, but it's a big change from all the years I've had these 17" machines.
Face the future, Bob… it might not be what you want, but it's all you have.
This morning I noticed that we have a new drop of Google Chrome dev to 26.0.1043.0 with some really nice release notes. OK… maybe they are just bug fix titles, with the Jira (?) tracking number, but it's nicer than the SVN commit logs of the past. And I think I mentioned this last time, but it bears out saying again - The update they have done to the page is really very nice. Clean, sharp, nice.
Thankfully, we're still getting a nicely optimized rendering engine so that we're not getting a lot of flash in repainting the same page on refresh. That's a nice touch, I must say.
This morning I put a lot of effort into making the selection of the children from the postgres database faster. There's just no way it needs to be 30 sec. Since I'd already tried the sub-select, I needed to have a completely different approach. Thankfully, I have a lot of ideas, and it didn't take long to find the one that solved the problem.
The problem is that I was always looking in the "wrong direction". I was using IN and joins, when it was really a much simpler problem. Let's find all the demand_id values from the demands table - based on the demand_set_id - which is keyed. This is a very fast request. Then we use that as a cursor to get the locations based on that.
There are a few nice things with postgresql that make this even nicer - like the FOR loop with the select embedded - very nice. Turns out to be really pretty simple:
The difference was dramatic. Now it's about 450 msec for the same load. That's a factor of 60x! I felt such amazement, what a lucky find!
Today I spent some time fixing a bug, and while I was in the code, I wanted to see if my manager was right - that I was writing code that no one on the team liked working with. After all, I'm new to writing in ruby, and there's a unique style, I've come to learn, and I wanted to see if I've been doing it right, or maybe not right enough. I had something like this in my code:
if meetings.empty? ru = fills * misses / factor fu = (1.0 / ru) * fill[0] else ru = fills.map { |f| f * misses / factor } fu = ru.map { |r| 1.0 * fill[0] / r } end all_zips = location.map { |l| l['zip_code'] }.compact.uniq { :ru => ru, :fu => fu }
Now, in truth, this makes no sense and I had about 10 lines in both branches of the 'if' statement, but the gist was that if the data was a constant, do one set of calculations, and if it was a vector, then do a slightly different set, but along the same lines as the single-valued calculations.
Nothing complex.
But it seems that The Ruby Way is to make anything that's more than a line or two into a new function - even if it's significantly expanding the lines-of-code in the file. So contrary to my prevailing understanding of the reasons for this extreme composition, it's really about the complexity of the code.
I was talking to a consultant new to the group, and his statement was that he trusted the code to do what it said it was doing, and by making the methods very small, and well-defined names, it was easy to understand what they were doing.
I asked him about debugging, and his statement was again about trust.
I was shocked. On so many levels.
First, that trust had anything to do with debugging. Second, that they felt this code was too complex, and required refactoring.
It's a few lines - say 10, and it's a series of calculations. There's no savings in making it functions. It's adding stack calls, tests on the input values, and re-testing the values that caused the branch in the first place. It was horribly less efficient than before, but that's what they wanted.
It's back to the "CPU cycles are Cheap - Dev cycles are Expensive" - Hogwash that I've heard before, and don't agree with in the slightest bit. Nothing is cheap. Everything is expensive, and it's all about balancing the costs of different factors into the final design. There's no free lunch, but it seems that fact hasn't found the Rubists yet.
Secondly, you never trust code in the debugging. You 'single-step' all the code when you have a bug to find out where it lies. If you trust code, you're going to get burned. Guaranteed. Debugging is a thoughtful exercise. You have to think what should happen, and then watch and see exactly what does. This means you can't take anything for granted. Not a single thing. That they would makes me very nervous that "fixes" on their part aren't going to be fixes at all. They'll patch or "refactor" until the bug goes away, but that's not the same as really fixing it. It might just pop up somewhere else.
Finally, I can't imagine that I'm going to be able to write code like this long-term. I don't see it as overly-complex, so I'm not going to think that it needs refactoring. If I take the absurd approach that every calculation is a method, I know I'll be wrong on the other extreme, so I can't just pretend to know what to do.
I'm frustrated, and I feel like giving up. It's been a hard day, and by all measures I seem to be incapable of getting the right mindset to write this code like the rest of the team. They aren't happy with my code, and they aren't willing to put in the hours to write it before I do. So they are going to complain about it, and I'm going to be powerless to understand their mindset properly to write code like they would.
I wish I knew what I could do to fix this problem…
I switched from Terminal.app to iTerm2 about a week ago because I liked the way it's double-click selection was controllable in preferences, and each tab in a window was selectable with the Cmd-1, Cmd-2, etc. whereas Terminal.app uses this to switch between windows. Not typically how that hotkey is used in other apps I use.
Plus, How different could it be - really? kept running through my mind. It's a shell. Should be pretty simple. Well… it's not that simple, and I've finally had it with iTerm2.
In the past week, large outputs to the terminal have crashed the entire iTerm2 app. I'm not saying that if it were like Chrome or Safari, and only the one shell session crashed, I'd be "ok" with it, but to have multiple windows with multiple tabs crash on you due to one tab is more than a little annoying to me.
So I'm heading back, and I'll probably never switch off it simply because Terminal.app never crashes on me. Just never. The convenience of the selection and tab switching would be nice to have, but I just can't have a crashing terminal program. Nope.
This morning, with the right help, I was able to put up a slick little javascript JSON viewer on the main 'metrics' web page for the project I'm on at The Shop. The goal of this is really a quick way to allow folks - both developers and support folks, to look at the details of the Demand objects in the demand service. Since each demand has a UUID, it's possible to look at the series of the demand objects as it "flows" through the service and is adjusted, combined, and delivered to the client.
I have to say that I'm very impressed with the speed of the clojure service. Then again, it's java, and there's not all that much to it - there's the indexed postgres table, a select statement, and then formatting. Sure, that's a simplification, but it's not like we're delivering streaming video or something. But wow! It's fast.
And the regex-based JSON classifier in javascript is pretty impressive as well. It's fast and clean and the CSS is a lot of fun to play with in the syntax highlighting. I can really see how much fun this can be. Big time sink, if I played with it too much.
But it's nice to punch it out and make it available on the much improved unicorn/nginx platform. Those timeouts are gone, and the code is much simpler, and that's a wonderful thing.
Late yesterday I found a slick little javascript-based JSON formatter and syntax highlighter. What I was looking for was a simple and easy way to get the JSON data out of the demand service and display it to the user. The point was to have a clean way for the users to be able to see the low-level data for a specific demand in a nice way so that they can look into problems without having to go to a developer or support person.
The project manager said that we didn't need to have anything fancy - just display the JSON data for the object as it's reasonably self-documenting, and most of the folks could figure out what they needed from that. For the more serious use-cases, we're still going to need to have a more comprehensive dashboard, but for now, this would be something we could whip up pretty easily and solve 90% of the need.
The code was really amazingly simple:
I have the classifier and then the CSS for the individual classes. Then I just have to hit the server based on the demand ID and show the results. Very nice and clean.
Pretty stylish, too! I'm impressed.
I've been having issues with timeouts on a web app that displays certain metrics for the main project I'm on at The Shop. The set-up is that we have a Sinatra app - using the Unicorn server behind an nginx server that's a gateway for the service. I didn't set this up, so I can't really say Why we have the nginx server in front of the unicorn server, as the point of the unicorn server is to handle the load nicely, and it's all on one box, so we're not getting redirection, but for some reason we have this set-up, and we're getting these timeouts.
Initially, I tried to have an EventMachine timer that sent a NULL to the client every 10 sec. This appeared to work, but then we started having issues with the thread it was in dieing. Then we had to put in a check-with-restart on each call. Things clearly weren't getting any simpler, and then I decided to try to convert everything to jruby from MRI, as we really didn't have any good answers as to how this was being deployed and configured. There were just too many holes.
So I reached out to one of the guys that was supposed to be the architect of this deployment scheme. I didn't know who it was, but when I found out I was really quite pleased - it was a guy that I've been interviewing with several times over the course of the last few months at The Shop.
He explained how the deployment was done, where the config and init.d scripts were generated, how to modify their generation, and in short, how to get rid of the timeouts by simply changing a few of the timeouts in the unicorn and nginx servers. So I took his advice, stripped out the EventMachine stuff from the code and then gave it a whirl.
Worked like a champ.
What a difference getting the right help makes. Inside of about an hour I had all the information I needed and had a solution that was cleaner, easier, and more maintainable than I had started with. The problem seems simple: find help, get it, and solve the problem. But too many folks - including me, initially, didn't do that.
Shame on me.