Archive for the ‘Uncategorized’ Category
In one of my recent tweets I noted that I had been reading through Fredrick Brook’s The Mythical Man-Month again when the mind needs a break in the office. In between all of the dated, but fascinating, technology references there is plenty of gold to mine.
One of the striking organizational skills he goes over is the construction of a programming team. I have worked in plenty of different small-medium sized organizations, but I have never been involved in a genuine single-project group-development effort. It has been a single programmer working in isolation. Or, at best, two programmers splitting a project down the middle with a static and defined interface (this tactic is also described in the book).
Only now am I working in an actual group where roles are given. Some of Brook’s roles are: tool-master, architect, and specialist, and program manager. Obviously I don’t need a batch tape scheduler anymore – but the above roles are very key. The program manager represents the client and user interests. The architect represents the sole owner of technical implementation decisions. Now, in all the other organizations I’ve been a part of, these roles undoubtedly exist. There might be two or more people competing or fulfilling these roles – but they exist. What I had not previously experience was the tool-master and specialist.
The tool-master is solely responsible for creating the tools necessary for the team to do their jobs. I’ve seen this manifest as; deploy scripts, local environment tools to mock out production infrastructure, and using and contributing to open source projects (we do not suffer from NIH syndrom). Sometimes this person is me. Sometimes it is not. But the tool-master is always responsible for his tools and to keep them up to date, and to keep the team informed about how to use them. Without this last point members of the team are wasting time figuring something out that has already been done.
I have experienced the specialist to be one of the most invaluable assets to the architect. If the architect is responsible for the whole system and writing most of the code what happens when he or she hits a small thorny problem. Sometimes it is an incompatibility between two pieces of software, or server settings. But whatever it is, someone has to take the red pill and go down the rabbit hole. If your architect goes in, he’ll come out a couple of days later with the beginnings of a beard, and a solution, but features won’t have be written. It is crucial to have a specialist who can take these thorns that need fixing.
All in all the amazing discovery I am witnessing is the overall level of communication on a team that quickly figures out how to design, architect, and implement projects; figuring out the limitations and ways to solve and overcome them.
So, we spent an embarrassing amount of time here at AF HQ recently wresting with this issue – what seemed like a migration bug in easy-thumbnails (a Django image thumbnailing app to replace the now-basically-defunct sorl-thumbnail).
The symptom was a failing migration (we use South for schema migrations, and easy-thumbnails provides the migration scripts for itself). More than halfway through (migration #10 of 13 I think), we got an error about not being able to drop a foreign key:
[...] raise ValueError(“Cannot find a FOREIGN KEY constraint on table %s, column %s” % (table_name, column))
ValueError: Cannot find a FOREIGN KEY constraint on table easy_thumbnails_source, column storage_new_id
The answer, which the title of this post sort of gave away, is that MyISAM doesn’t support foreign keys, and this particular database happened to have a few (and the server was set to create MyISAM tables by default… because it’s a per-server, not a per-database setting). Still, why did it take so long to track down the particular problem here? Because the error didn’t point to the ADD FOREIGN KEY statement, which would have made the problem fairly obvious, but rather the DROP FOREIGN KEY statement, which didn’t exactly illuminate the problem.
According to the docs:
“For storage engines other than InnoDB, MySQL Server parses the FOREIGN KEY syntax in CREATE TABLE statements, but does not use or store it.”
So the migrations blissfully buzzed through the foreign key creation, but died on the DROP. I’m sure there was a good reason at the time for this “we’ll just silently ignore your ADD FOREIGN KEY statement” behavior, but it makes debugging things like this pretty damn hard.
Moral #1: Just don’t use MyISAM.
Moral #2: See Moral #1. OK, that’s a bit rash; there are, of course, specific cases where MyISAM outperforms InnoDB; but InnoDB should really be the default, and it’s a damn shame that on many systems it isn’t.
We’re excited to announce a new strategic partnership with Above The Fold, a fabulous user experience firm that we’ve collaborated with in the past and are pleased to call friends as well as colleagues.
Together, we’re going to be focused on providing a complete web & mobile application service offering – from user stories, wireframes and prototypes to design, development and post-deployment analytics.
We’re doubly excited because we’re not just going to be collaborating more closely with Above the Fold, but actually sharing space – a spiffy studio in beautiful (and occasionally sunny!) Central Square, Cambridge.
Above the Fold has a more complete write-up on their blog, which we highly recommend for all sorts of UX/UI insights – so we’ll just add that we too are super-excited about the partnership, the space-sharing, and the awesome things we’re going to build together.
In Part 2, we started an Android project, poked around it a little, and launched an emulator. Now we’ll move on to making the app look like what we want.
You’ll notice I titled this part “Describing Your Layout,” not “Coding Your Layout” or “Programming Your Views.” This is because Android gives you the tools to define most of the characteristics of your Activity’s visuals in descriptive, not procedural terms. This helps speed up development, thanks to the nice GUI-based tools for layout, and helps you keep your programming logic out of the places you define your application’s outward appearances (and vice versa). It’s important to know that you could create your entire app in Java, writing the descriptive code for your layout procedurally in your Activity instead, but it’s a much better idea to keep things separate wherever possible.
We’re going to build a basic Twitter client, so let’s make it look like one. Let’s switch back into Eclipse and poke around at what we have so far. You’ll recall that besides our Activity’s Java file, we have layout and strings files in the res/layout and res/values folders. Let’s go check them out.
Here’s the basic layout the wizard created for us in res/layout/main.xml:
MySQL, how ridiculous you are. But seriously, though – what are you thinking?
I learned today (belatedly perhaps) that joining a VARCHAR field to an INT field does something… interesting. To illustrate, try to follow along:
CREATE TABLE `test` (`col_int` INT, `col_str` varchar(10));
INSERT INTO test(col_int, col_str) VALUES (1, '1'), (2, '1, 2'), (3, '2, 3');
SELECT * FROM test t1, test t2 WHERE t1.col_int = t2.col_str;
A pickier database would probably scream about type incompatibilities. But MySQL… MySQL doesn’t care, and silently truncates “1, 2″ to “1″, which it then casts to an int. And this is how you get the string “1, 2″ being equivalent to the int 1.
Only in MySQL-land.
* PostgreSQL fans: I know, I know. Shut up already.
Much of the response has come from Drupal/Wordpress/[other CMS] developers, and channels a few common threads:
1. But what if you just want a blog?
2. But you get lots of stuff for “free” (forums, etc.)
3. But look at [awesome NKOTB CMS] – it solves every problem you mention!
Well, yeah. If all you actually want is a blog, then just use a blog – Clay himself points out that Sunlight uses WordPress (as does this blog). The argument is really directed at larger endeavors. If you really do just want a blog, or for that matter any specific feature that has a well-tested, well-maintained off-the-shelf implementation, then by all means just use that. But that’s not the point.
The point is that when deciding whether to: a) spend serious money in CMS customizations, or b) roll your own platform with the help of Django/Rails/[other framework], option (b) is a better choice in more situations than people think. Why? Because the decision to customize a CMS vs. building something “from scratch” is deceptive, since the “framework tax” of a CMS is more hidden than the obvious blank slate you get when working with a framework.
To use a slightly facile analogy, imagine you’re looking to build a house, and you have (because you’re really picky) very specific requirements. Let’s say that you find a house in a perfect location that’s almost what you’re looking for – you just need to add a third bedroom. In that case, adding on to the existing house might be considerably cheaper than building it from scratch.
But let’s imagine now that the house you found is actually nothing at all like the house you want, and you’ll have to raise the house on stilts, dig up the foundation, add a floor underneath, re-do all the plumbing and electricity and add an attic to fulfill your particular requirements. At that point, it’s highly likely that just building it from scratch will be cheaper than bending over backwards to reuse parts of the existing house – particularly if you can get many of the same components for free elsewhere (let’s say the neighbors are giving away perfect pre-fab kitchens that can be easily plugged in to any house).
Obviously the analogy has holes, and I’ve probably barred myself from the building industry for life, but the point stands – the cost of working within an existing product can be deceptive because the difficulties of working within its rules are less obvious than the missing parts on a blank slate.
It always looks like you’re getting all this stuff with an off-the-shelf CMS – “We won’t have to write any login code! Forums come pre-built! The widgets fidget all on their own! Hallelujah!” The trick is, though, that if you’re already having a conversation about the 10 different things you need to customize in your CMS to make it fit your workflow, there’s a good possibility that the stuff you’re getting for “free” will actually make it harder to do anything else. (And some of the pieces – like user management – are standard parts of most mainstream MVC-style frameworks as well).
Will the “anything else” be possible? Of course. Apparently there are at least two full-featured shopping cart WordPress plugins. Hell, you can implement a C compiler as a WordPress plugin. That doesn’t mean you should, and in fact implementing a C compiler as a WordPress plugin would be considerably more effort (and probably produce a messier result) than just writing the damn thing from scratch.
As with everything else, you have to assess the individual situation and make informed choices. If an off-the-shelf CMS (or other product) really fits your requirements perfectly, then of course go for it. But if you’re going to be making a substantive investment in technology, because nothing quite fits your needs and you’ve made the decision that doing X is a worthwhile effort, remember that even the “free” pieces of a CMS impose a higher “developer tax” when extending the system.