Time Flies When You're Coding at Scale

Leave a reply

A wise man once said: “Life moves pretty fast. If you don’t stop and look around once in a while, you could miss it.”

ferris

He wasn’t kidding.

It’s been a year since I joined a fast-paced, high scale e-commerce company (with a great engineering team) called Wayfair – so now is a fine time to stop and look around at what I’ve learned (hint: a lot).

I’ve worked on scaling systems, implementing new business initiatives, internal tooling and even responding to issues in production. Before joining Wayfair, my day-to-day work was in the Java stack (JSP, Spring) with jQuery and various databases underneath. Now a typical day could involve any of the following: jQuery, PHP, Redis, C#, Python, Hive, TSQL…and the list continues to grow.

There are thousands of little details that go into building scalable, resilient systems. Here are some of the most important lessons I’ve discovered, one way or another:

Time problems are hard

This isn’t anything groundbreaking, but time problems are really tricky to think about unless you think about them correctly. This kind of thing usually isn’t an issue for your single server / single database web application, but when you’re working on a global scale site and need to perform logic based on a user’s local time: make sure you know what you’re doing. I’ll just leave this here: http://unix4lyfe.org/time/?v=1.

Failures happen.

As the number of technologies, servers and business rules increase – the opportunity for failures increase. This is simply a fact of life that needs to be burned/scarred/tattooed into the engineer’s mind before embarking on a new design, or a change to an existing codebase. For example – you know that really great caching feature you just setup that allows you to retrieve data in < 10ms? Do you know what your app is going to do when the server goes down, or the cache process restarts? If you don’t…you should. The Chaos Monkey is your friend.

Caching is awesome, but brings complexity

Speaking of caching, have I mentioned how amazing it is? I find it very entertaining to watch a graph of cache hits / misses and monitoring the response times of corresponding calls (more on that later). However, this additional layer of data retrieval brings with it some hard problems that computer scientists have been struggling with for years. Aside from the failure scenarios mentioned above, a cache begs many questions: what is a good TTL for this data? What happens when the cache fills up? Do we really need to write the cache data to disk…or can it just live in memory? This all depends on the specific use case, and there is no “one size fits all” solution. Oh wait…what about when something changes that affects the cached data – how do I invalidate the cache record? There are only two hard problems in computer science…

Measure EVERYTHING

Easily my favorite part of working with code that gets hit millions of times per day is all the data and stats that can be collected, monitored and analyzed. Without this, it would be like driving an 18-wheeler down a highway blindfolded – sure you *think* you’re heading in the right direction, but you also might quickly find yourself in a ditch. Statsd, logging frameworks, graphite and other tools make gathering data on a recent code push extremely easy and with minimal overhead (using UDP) – that way, you’re not driving blind and can have more confidence in future decisions. Oh and while you’re at it…make sure you’re actually measuring what you think you are – it doesn’t count as a fast response time if the measured code is failing because of a bug :-)

 

In general, I think working at high scale just accelerates the learning process for an engineer. Especially when you’re writing and/or deploying new code everyday. And if you’re not learning, you’re not doing it right.

 

Learning a new technology? Slow down to speed up.

2 Replies

When I think of becoming a faster runner, I think of one quote:

“Train, don’t strain.” – Art Lydiard

Arthur Lydiard was a proponent of long, slow distance to get faster over time. Having taken running “seriously” for over 15 years (i.e. actually caring about getting faster times in races more often than not), I can’t agree more. A runner can’t run hard every day and expect to get faster – in fact, doing a hard workout every day is the quickest way to getting slower, burnout and/or injury.

I believe the same goes for learning a new or different technology.

I’m a hard worker by nature, but sometimes that can backfire and lead to slower development overall (working too much, overthinking things, making stupid mistakes, etc). It’s better to slow down, understand the fundamentals, and let the knowledge come as slowly or quickly as your brain allows it.

This topic is on my mind, because in the past three months I’ve been working with YUI, PHP, Classic ASP (yes, you read that right), C#, Redis and Hive: all technologies I’ve had little to no experience with. All the new (and not-so-new) shiny technologies are awesome to work with, but real deadlines and schedules sometimes cloud the mind. The funny thing is I’ve posted about this exact topic in the past year (even used the same quote!), and completely forgot about it. Clearly it’s not an easy thing for me.

In the end, taking that extra hour or two to relax and really understand something will pay off in the end. It takes self-confidence, restraint and a lot of patience…but the cumulative gains are worth it.

2011: Hacking Year in Review

Leave a reply

2011 was a memorable year for me in many ways – most notably that I got married, moved into a new place and spent two amazing weeks relaxing in Aegean Sea (well, technically I was on land most of the time).

This year also marked a big boost in my focus as a developer, in that I completed my MS in Computer Science – which ironically allowed me to learn more in six months than I have in most classes in my degree program. Instead of passively consuming information from classes and class projects, I was free to pursue that which interested me. I made a conscious effort to spend less time perusing blogs and HN articles, and more time actually creating something…anything. I believe this is the right path to becoming better at what I do and enjoying every minute of it.

I’ll first list some of my failures, because no good YIR post is truthful without them:

  • I started iPhone development, but I started it the wrong way and eventually lost motivation. I tried watching some of the Stanford course videos, bought a book, but never created a project that excited me enough to continue learning. Perhaps I’ll get back to it, but for now I’m heading in other directions.
  • I still spent too much time on HN, reading blogs and listening to podcasts that don’t directly relate to a project I’m working on. I need to improve on focusing on one thing – towards the goal of “just ship it”.
Here are some accomplishments, and signs of hope for the future:
  • This domain and blog! Born this year, thanks to my brother-in-laws hosting business – which is now called HostAVPS
  • Finished my Masters degree in CS, for what it’s worth. After a Bachelors in IT and Masters in CS, I feel I’ve learned the most by doing personal projects and actually working as a software developer. Some of my classes were great though, and something I wouldn’t have pursued on my own time (e.g. analysis of algorithms and operating systems come to mind…)
  • Jumped in with both feet to Python and Django. I built a small web app that decodes Entrust Grid Card challenges as a first project, and actually sent it to some coworkers to try out themselves. This project started as just a tiny python script to do some array manipulation, and grew into a hosted web app. It allowed me to start using Bootstrap CSS toolkit, more jQuery, Django, and learn some of the aches and pains of deploying to a French hosting server. Oh, and github too.
  • Started attending Boston Python Meetups. OK, only one so far…more next year. I really think Python has a great community behind it, and I’m excited to see where it takes me.
  • Doing more jQuery and CSS work in my day job. I was even sent to jQuery Boston Conference, which was an eye-opening experience to the power and community of JavaScript.
  • Did a few jQuery gigs on odesk for a German website…essentially organizing their code a bit and adding lazy-load functionality. jQuery gives me super powers as a developer.
In 2012, my single focus will be to BUILD MORE STUFF. Bottom line. I’ll continue with Python and Django, and I’ve already got a few ideas brewing for some fun, small projects I could start with and build on. I’m signed up for the NLP Stanford class this January, and I’m hell bent on using the knowledge I learn in one of my first projects. Oh yeah, my other non-development goal is to meet more developers. I need some people I can talk to about all this nerdy stuff…
Happy Gregorian Calendar New Year!

The absolute maximum I know about Unicode and character sets (thanks to Joel)

Leave a reply

I’ve read Joel on Software’s blog post about encoding at least three times all the way through over the past couple years. After each read, I quickly forgot the difference between ASCII and ANSI, Unicode and UTF-8. Rather than continuing to reread it everytime I forget all of this, I figured I’d try to commit the knowledge a little better by writing some of the key notes down myself. I’m making a big assumption that encoding standards haven’t changed all that much since 2003 (I haven’t heard of any exciting encoding breakthroughs on hacker news…UPDATE: I stand corrected – here & most importantly here).

EBCIDIC – I vaguely remember this acronym from an Architecture of Hardware and Software course in undergrad. Joel says it’s ancient history and to ignore it, which is fine by me.

ASCII – Utterly screwed up. Uses 7 bits to store a character, with the 8th free bit being used for all sorts of crap. This is where the IBM-PC introduced OEM character sets, with fancy accented characters, different lines and bars to draw with, etc. Problem is that PCs in different areas of the world had different character sets, causing problems when sharing docs between different places in the world. All this OEM stuff got codified into the ANSI standard at some point. ANSI uses code pages to describe the use of the 8th bit (characters 128 and up). For example, MS DOS had all these code pages for Israel DOS, Greek DOS, etc. to support the specific characters in each region. Asian character sets were never going to fit into 8 bits, since there are thousands of letters in those languages. Instead they used a DBCS, “double byte character set”, where some letters took up two bytes and others only took up one. Yikes.

Unicode – There is actually a Unicode Consortium which came up with a better character coding standard (What’s it called? hint: “Unicode Consortium” is not just a clever name). Sounds like an interesting gig, but it’s gotta be mind-numbing at times…Anyway, Unicode is NOT simply a codeset where each character uses a 16-bit code (common misconception). Unicode uses code points to represent letters. Every letter is assigned a hex number, and is prefixed with U+ (meaning “Unicode”). The platonic letter A happens to be U+0041 (Note: “A” is a different platonic letter than “a”).

The charmap or Character Map utility on Windows contains all the Unicode characters. On Mac OSX its called Character Viewer.

In Unicode, the word “Hello” corresponds to the following code points: U+0048 U+0065 U+006C U+006C U+006F

How is this stored in memory or written in an email? Using Unicode Encoding. One idea for this was to just map the code points to two bytes each (UTF-2), e.g. 00 48 00 65 00 6C 00 6C 00 6F. There was an alernative way of storing the code points, which caused some problems and people weren’t happy with how much space it took up….yadda yadda yadda, UTF-8 was invented.

UTF-8 – An alternative way of storing your Unicode code points in memory, using only 8 bit bytes. Every code point from 0-127 is stored in a single byte, only those 128 and up are stored in more bytes as needed.

UTF-16 – Same as UTF-2. 2 bytes, or 16 bits.

“There are hundreds of traditional encodings which can only store somecode points correctly and change all the other code points into question marks. Some popular encodings of English text are Windows-1252 (the Windows 9x standard for Western European languages) and ISO-8859-1, aka Latin-1 (also useful for any Western European language). But try to store Russian or Hebrew letters in these encodings and you get a bunch of question marks.”  - This doesn’t happen with UTF-7,8,16,32. Of course, there are also font limitations…

A string alone is not enough, you must also know the encoding it uses:

  • In email, do that like so in the header: Content-Type: text/plain; charset=”UTF-8″
  • In a web page, do that like so in the <head> section as the first entry:
  •      HTML4 - <meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″>
  •      HTML5 - <meta charset=”utf-8″>

All of this is important for internationalization on a website, though there is more to it than just encoding. I’m sure I’ll run into the implementation nuances all this business in Python (and Java) at some point soon…

Python and Django hacking

Leave a reply

 

    I’ve been slowly teaching myself Python and Django by working on a small web app (Wednesdays are hack night, when my wife is at grad school ;-) ). Tonight I had hoped to make it to the Boston Python Meetup, which boasts over 1k members and had over 100 rsvps for tonight’s session. Unfortunately my dog got sick, so I’ve been doing the usual hack/fix/repeat cycle myself at home.

Even without getting real life human help, the tools and environment have been relatively easy to get started with. I’m surprised how little I’m checking stackoverflow and google. With absurdly descriptive error messages like this from Django, why would I need to?:

You called this URL via POST, but the URL doesn't end in a slash and you have APPEND_SLASH set. Django can't redirect to the slash URL while maintaining POST data. Change your form to point to localhost:8000/openid/login/ (note the trailing slash), or set APPEND_SLASH=False in your Django settings.

jQuery Conference Boston 2011 Recap

Leave a reply

As promised, a recap of my experience at the jQuery Boston 2011 Conference. I plan to share the info from these talks with my team at work, where we’ll hopefully implement some of it. I’ll definitely use some of this in my personal projects now and in the future.

A few main themes from the incredibly fun and brain-expanding weekend:

  1. JavaScript developers are crazy. Some of the funniest presenters and conference attendees I’ve ever come across. Other conferences I’ve been to (NFJS, DevDays) haven’t been this much fun.
  2. The jQuery community is awesome! You can tell the whole jQuery team and all the developers who get involved in some way really care about the API, code quality and making developers’ lives easier.
  3. You can build some serious applications with only HTML, CSS and jQuery/js. Coming from a background in internal web applications, built using a “classic” architecture with JSP/Java/SQL with a sprinkling of jQuery on top – I was blown away by the capabilities of some of these newer frameworks like Node.js, Backbone.js/Spine.js and even jQuery itself.
Below are the talks I attended, along with my observations and some notes I found interesting. I was often torn choosing between two talks, and hope to look through all the slides at some point. The quality of speakers was great! Inspires me to give a talk at a local meetup sometime. Some slides are posted here (I’ll link them below directly when possible): http://events.jquery.org/2011/boston/schedule/

(This won’t be brief. TL;DR: If you like writing jQuery and JavaScript code, go to the jQuery conference. Hilarity and learning ensues.)

(Proof that I was really there and enjoyed cups of coffee)

Day 1

jQuery Keynote – John Resig

John is a great speaker. It was interesting to see some of the usage statistics of jQuery, and get aninside look into how the team is thinking.

  • jQuery is soon to be used by 50% of top 10,000 sites on Internet. It is currently more popular than Flash…
  • 1.7 beta 1 is out, complete with a simpler Events API! (.on()/.off() instead of .delegate(), .live(), .bind())
  • John also went into how to get involved with the project, and how the core team operates

jQuery Mobile Keynote - Todd Parker and Scott Jehl

Wow, jQuery Mobile looks amazing. Extremely easy to get started and have a great looking mobile site with jQuery magic enabled. Todd and Scott work for Filament Group, the company who redesigned BostonGlobe.com – the site looks really sharp with its progressive enhancement fanciness.

  • One useful feature is prefetching HTML, by using the “data-prefetch” attribute in your anchor tag: <a href=”prefetchThisPage.html” data-prefetch> … </a> or by using jQuery’s $.mobile.loadPage()
  • The demo of the new Themeroller was equally amazing. My favorite part of that is the “pick a main color, get some nice-looking secondary colors if you’re not a designer” feature…
  • More info at the jQuery Mobile blog

Attributes and Properties in jQuery – Timmy Willison [slides]

Timmy admitted he was nervous before this talk, but he loosened up with the audience questions – Audience Member: “What’s your favorite property?”, Timmy Willison: “Window.location. It’s very existential”.

  • Essentially the .attr() method caused some confusion and bugs in earlier versions, and the .prop() method has been introduced in 1.6 to address that.
  • .prop() will always give the current value of an input’s property, even after user interaction. .attr() will give the initial value only.
  • .prop() is faster than .attr()

Node.js for frontend developers – Garann Means [slides]

I’d been hearing about Node.js so I was interested in this talk. Node is a server side javascript framework – that’s right, JavaScript on the server side…wacky stuff, but it would be nice to limit the # of languages in building an app. We didn’t get much in the way of a demo or example apps, but I did learn enough to know I’d like to play around with Node to find out if it’s “something I might be interested in”.

  • http://nodejs.org/, runs on V8 js engine
  • Avoid the cross domain issue by making cross domain calls on the server!
  • Packages for anything you can think of…much of the work is done.
  • Recommended packages from npm: express (app framework) and socket.io (async communication)

Extending your jQuery application with AmplifyJS – Elijah Manor [slides]

I enjoyed this presentation, and will definitely be playing with AmplifyJS soon. Elijah also pointed out MockJSON, a tool for randomizing JSON data.

  • http://amplifyjs.com/ contains 3 components – pub/sub, persistent storage, and request
  • Pub/Sub is basically the observer pattern to decouple events and event handlers
  • Persistent storage picks the most useful storage for the browser, and can store anything that can be serialized to JSON
  • Request splits up the request config and the actual call, so they can be used separately!

 Chrome Dev Tools (audience chosen topic) – Paul Irish [slides]

Paul Irish’s talk was a late add to the agenda. I’d heard the name and knew I’d read some of his stuff, but didn’t really know much more about him. When I overheard several groups of attendees talking about Paul Irish like he was an idol, I figured I’d better check out his talk. He didn’t disappoint – I appreciate his dry humor and complete command of all things web, html and css. He had several talks ready, and the audience decided on “Chrome Dev Tools”. I use Chrome Dev Tools all the time, and still learned a thing or two.

  • Dev tools is just another app in html/css/js – so you can even inspect dev tools with dev tools
  • Keeps a complete history of local changes to css! Awesome feature.
  • Script pretty-printing feature is great. Use the {} icon. Think minified.js to an readable, breakpoint-able script
  • smus.com/devtools-cheatsheet

Plugin Authoring Best Practices – Ben Alman [slides]

Ben Alman is a jQuery plugin fiend. He’s created a ton of them, and I’ve used a few myself already (Thanks Ben!). One cool thing about his talk is that it was completely written in a .js file, which was a nice way of showing off the code in it’s native form, without swapping windows. The key thing I picked up is that you really need to understand what scope you are working with when you write a plugin. I’ve dabbled in created plugins before, but Ben’s talk gave me some more concrete things to look out for.

  • Best practice – empty param list is a get, param list is a set (follows jQuery standard!)
  • Slides show how to allow optional args in your plugin (line 603)
  • IIFE – Immediately Invoked Function Expression

jQuery’s Secret Weapon: .widget – Ryan Florence [slides]

Looking at my notes from this talk, I don’t remember much from it. Perhaps it was the late afternoon lull in energy. Nevertheless, I had a few key points jotted down:

  • UI widgets can be extended for your own custom needs! (e.g. default options you always use)
  • http://docs.jquery.com/UI_Developer_Guide#The_widget_factory
  • e.g. https://raw.github.com/jquery/jquery-ui/master/ui/jquery.ui.progressbar.js

Remote debugging with jQuery Mobile – Mike Taylor [slides]

I hadn’t considered that with mobile html websites, debugging could be an issue. Then again, I haven’t developed one. Mike works as a “Web Opener” at Opera…which is probably one of the most unique titles I’ve heard (aside from the BS startup titles like “Chief Technology Ninja”). There was some connection trouble during the demo portion (a common theme for the conference), but otherwise I found the talk useful and Mike’s use of humor helped save a failed demo.

  • General jQuery debugging tips: fixingthesejquery.com
  • Emulators aren’t always reliable, need to debug on the device itself
  • Current remote options: socketbug, weinre (note the spelling!) and opera dragonfly

(Note: I decided to skip the after party hosted by MediaTemple, because I was still hungover from Friday’s Harpoon Octoberfest…normally I wouldn’t pass up an opportunity to meet other devs and enjoy an open bar…)

Day 2

jQuery UI Keynote – Richard D. Worth

jQuery UI is already 4 years old. Sounds like some new widgets are coming in the next few releases, including a redesign of the datepicker, and a grid widget. This is great news for me, since we use datatables heavily at work and are always interested in better options.

  • Timepicker plugin to come (as part of datepicker redesign, more individual components!)
  • “Mask” plugin under development (to format telephone, ssn, etc.)
  • wiki.jqueryui.com for more info on development progress and demos

QuickUI, a web control framework – Jan Miksovsky

I happened to sit down at Jan’s table for lunch the day before his talk, so I had a chance to hear a little bit about QuickUI ahead of time. I’m always interested in frameworks which might make project development time a bit shorter, and entrepreneurial projects are always fascinating to me. QuickUI seems useful, but it was tough to get a real sense in just the short 1/2 hour talk.

  • quickui.org, used at cozi.com
  • Use markup to create javascript-enabled web controls
  • One downside is that ids are repeated in your markup
  • The beta version compiler is written in C#, so it requires Mono to be installed if you’re on a Mac

jQuery, You and I: Lookin’ Good Together – Adam Sontag and Rick Waldron [slides]

This talk was full of sword fights and crazy hair. The basic gist of the talk was that anyone can get involved with the jQuery project, and all participation is much appreciated by the project team. Also, follow the style guide, suckers.
  • Style guide - nothing too shocking here, consistency is key
  • “Curly braces every God damn time!”
  • “Your brain is your parser. Optimize your code to understand it easier later.”
  • Only case when == is OK is when you are testing for null and undefined…can test in one fell swoop with someObj == undefined

jQuery 1.7 Events - Dave Methvin [slides]

“Event API, better drink my own piss” – Bear Grylls

This talk, as advertised, was chock full of Internet memes. You know, those pictures and sayings that get passed around so much they lose their original meaning but for some reason are still really funny. This talk was equal parts informative and hilarious – great job Dave.

  • There are currently 3 event apis in jQuery 1.6 – live(), bind(), delegate(). This is bad. We want 1.
  • In 1.7, just use the new API – on() and off()
  • Faster event delivery in this version, due to fancy refactoring I didn’t quite follow :-)

Browser Plugins and jQuery – Sara Chipps [slides]

I heard one of the early “This Developer’s Life” podcasts where Sara was a guest, discussing some early career failures and getting fired. She seemed very into her craft on the podcast, so I decided to check out her talk at the conference. Browser plugins are something I haven’t considered dabbling in, but after seeing how easy it is, maybe I will.

Grow a Spine.js – August “Kai” Kaiser

This talk was more about Javascript MVC frameworks than Spine specifically, but it was a good heads up to all the MVC goodness out there for js. Backbone.js seems to be a big one in that area, along with SproutCore.

  • TodoMVC – implementations of a TODO list app in each of the MVC frameworks
  • Highly recommended js book – JavaScript Web Applications (O’Reilly)

CoffeeScript and You: Become a better JavaScript Developer – Mark Bates [slides]

CoffeeScript seems excellent. Reminds me of Python – less crap syntax, easier reading/writing. Compiles to js.

  • http://jashkenas.github.com/coffee-script/
  • Doesn’t let you use ==, as a safety net
  • Shorthand syntactical sugar for existential checks – console?.log means log only if console is present

Contextual jQuery in Practice – Doug Neiner [slides]

The kind of performance optimization techniques Doug went through seem critical for complex sites, with aggressive performance requirements. Unfortunately I work on internal applications, but the tips were great to think about either way. Doug gave a related talk last year, which I still need to check out.

  • “Write code like you spend money” – only bind your events when the user actually needs it (e.g. on mouseover)
  • “Write code like you buy a car” – consider the tradeoff between speed and cost (complexity)
  • Technique – base your event binding based on what is in view. If the user can’t see it, they can’t interact with it, so don’t setup those events yet.

Speeding Up the Future: How jQuery Can Help – Yehuda Katz (w/Paul Irish cameo)

This talk was a bit too much “inside baseball” for me. Seemed to be a lot of inside info on the jQuery team’s decision process in supporting certain features or not. There were even some team members taking shots via Twitter while Yehuda was presenting. Kinda weird. Also, it went way over the scheduled time – which would have been fine except it was the LAST talk on a Sunday…and I just wanted to get home and rest my brain.

  • jQuery probably won’t provide an API for all the new HTML5 features, because the HTML5 api is fine as it is
  • The flashback to core js APIs was a nice trip down memory lane. Ugh.

Why I'm excited for jQuery Boston 2011

Leave a reply

Yes, you read that correctly. I’m excited to go to a dev conference on the weekend. This Saturday and Sunday, about 8 hours each day of jQuery goodness starting at 9am. (Ok, for the record, I’d rather start sometime after 10…)

Most of the conferences I’ve been to have been on a wide array of topics, so I’d walk away with only a general awareness of different technologies or ideas – which didn’t always apply to the work I was currently doing. This conference is a different story for me. Based on the schedule of talks, I think I’ll get some specific techniques and tools that I can start using right away in my personal projects and my day job. I still need to make a call on which talk to attend in each time block.

jQuery is a framework I’ve been using almost daily for my JavaScript needs, and I really enjoy this part of my work. The framework is easy to understand, create plugins for and just plain fun most of the time. Also psyched to pick up some swag (I know a t-shirt is part of the registration, at the very least).

I plan to write up my thoughts on the conference here after the weekend, stay tuned.

Welcome to Southie

Leave a reply

 

Broadway T Stop

Broadway T Station, South Boston

I recently moved to the South Boston neighborhood of Boston, commonly known as “Southie”. There are plenty of stereotypes about the neighborhood, made popular by movies like “The Town”, “Gone Baby Gone”, “The Departed”, “Good Will Hunting”…oh – and there was also some gangster name Whitey who didn’t exactly help the reputation. Despite all these movies filled with (mostly) fake Boston accents, there is an influx of new residents (such as myself, my lady and my dog). It’s a community-focused area that doesn’t make you feel like you are in the middle of a giant city. Also, it’s right near the beach – which is a requirement for me.

Now, I prefer to form my own opinions of an area after living there a bit. However, there are some things that are helpful to know on day 1. Here are some of those things, in case you ever find yourself in my neighborhood (and because I enjoy a good list).

Cash Rules Everything Around Me

If you’re gonna be spending some time in Southie, bring cash. For whatever reason, many bars, restaurants, barber shops and other local establishments only accept cash – or strongly prefer it. The good news is, there is a Bank of America on W. Broadway, at least two Mount Washington Banks, and several other banks and ATMs all right in the neighborhood if you’re out of cash.

Hills and Stairs

Having lived in Boston for almost four years now, I don’t think of it as a hilly area. In fact, most of my running was previously done on the Charles River, which is flat as a pancake. Southie however, feels more like San Francisco with some of the massive hills you have to run or walk up to get around. I live about 1/2 mile to the sand of the Pleasure Bay beaches, but in order to get there I need to climb the Dorchester Heights/Thomas Park mountain. Great views of downtown, but jesus that is a hell of a hill to run up at the beginning and end of a run.

The other steep spots to watch out for are the narrow stairways in condos and apartments. The majority of housing was built back in the late 1800s and early 1900s, and most are on small plots of land. In order to squeeze in more vertical space, most places have super narrow and steep stairways. You will get your exercise here in Southie.

Not From Around Here?

If you run into someone who was born and raised in the neighborhood, they will know almost immediately that you are not a local. Don’t ask me how – maybe because it’s such a tight community that everyone knows everyone else, at least on the family level. Regardless, be prepared to be asked “So where are you from” and then hear about how different things are nowadays. The good news is people have been very friendly, contrary to some outsiders point of views on the folks that live here.

Double Parked

Ok, so most of the time when you have two lanes going in one direction, you can drive in either the left lane or the right lane and get where you need to go. Not so in Southie. The right lane is reserved for “double parking” for people to run into a store, grab a coffee somewhere, or sometimes have a sit down meal. It is the de facto standard to just not drive in the right lane, in order to allow this convenience for all of us. If you happen to be a car which is blocked in…tough shit. Welcome to Southie.

Leapfrogging Tomcat Releases

Leave a reply

My team is upgrading from Tomcat 5.5.23 to Tomcat 7.0.14 at work. I’m excited about this, because the server version we’re using now is over 5 years old (yikes!). The 7.0 upgrade will force us to start using Java 6, and allow us to take advantage of Servlet 3.0, JSP 2.2 and EL 2.2. Tomcat 7 also has some improvements in memory leak prevention/detection and security features. Hooray for progress – but how should we proceed?

Sometimes it’s harder to jump over a major version (e.g. Tomcat 6.0), but in this case it wasn’t so bad – with a few minor tweaks. Here are some changes we had to make, to our applications and to our application server:

Application Changes

  • Upgrade to JDK 6 (required by Tomcat 7)
  • Fix any JSPs which violate the JSP spec regarding nested quotations (note: this issue presents itself as a runtime error)
  • Remove entries from your web.xml (auto-discovered as of JSP 2.0) and update tlds so they have URI value set. Change JSP taglib references to point to this URI. See this link for more details

Server Changes

  • If you are installing Tomcat 7 alongside another Tomcat instance as part of your migration, open the server.xml file and update the following default ports to avoid a conflict on startup: SHUTDOWN (default 8005), AJP Connector (default 8009), STARTUP (default 8080).
  • To find ports which are currently being used (on a windows server), use the following command: 
    netstat -an |find /i "listening"
  • Make sure your JAVA_HOME is set to a JDK 6 install
  • Set CATALINA_HOME appropriately before you start Tomcat 7. In our case, Tomcat 5.5′s CATALINA_HOME was the default for the machine. So I set the CATALINA_HOME variable for my current command line session - 
    set CATALINA_HOME=C:apache-tomcat-7.0.23

    - then installed the Windows service -

    service.bat install

That’s about it. Coming from an environment where I used IBM Websphere Application Server – I really appreciate the simplicity of Tomcat configuration.

If anyone has additional issues they ran into, feel free to comment.

Continuous Learning

Leave a reply

Another of the 97 Things Every Programmer Should Know.  (As I mentioned in a previous post, I agree with most of the 97).

Continuous Learning is a requirement that makes a career in software development unlike many other careers. It can be overwhelming to think about how quickly standards change and new technologies become old. How many other industries require you to constantly learn new ways of working?  This consistency of change is also what makes software development interesting and fun, even after years with the same “title”. Ever since I started working (which is when I realized the passive learning I was used to in school wouldn’t cut it anymore) I’ve been actively seeking out new information to get better at what I do. Continuous Learning can be achieved in many ways, here are some that have worked for me:

  • Talk to coworkers about their thoughts on design, code, new technologies, etc.
  • Read technical blogs from leaders in the software industry (RSS is your friend here)
  • Stackoverflow
  • Attend a conference at least once a year
  • Do something completely different in your spare time (For me lately, it’s been Python and Objective-C/iOS development)
  • Seek a deeper understanding of the code you write or systems you work on
  • Go back to school…

I’ll discuss going back to school in a future post. Recently I completed a Master’s degree in Computer Science. I’m happy I did it, but learned that improving as a developer takes more than a framed degree.