This week hasn't been great for my productivity. It has been a series of days overshadowed by a series of things coming up. Between standing in line at the DMV, computer issues, and today helping my brother-in-law with a very sudden move, it feels like typing is an unfamiliar act. (Unless its on the T-Mobile G1, which I'll be reviewing this weekend.)
Thursday, October 30, 2008
Tuesday, October 28, 2008
Just let these guys do it for you.
Monday, October 27, 2008
- Forget what you did yesterday. Check!
- Decide that all problems can be solved not just with software, but by adding new software just for that purpose. Check!
- Get written about on the popular ReadWriteWeb so people find you. Check!
- Be nifty enough to grab someone's attention when they try out the new service. Check!
- Surpass a plain text file in convienience, flexability, privacy, and install base. Damn! Maybe next time.
Once again, making any claims or arguments in this discussion has to start by defining what we're talking about in the first place. Are we talking about the choice of first runtime (Python) and included libraries (namely, the Django templates)? Is Google's design of the Datastore API and what other service APIs they provide the import factor to praise or ignore? Perhaps the details of their hosting plan makes it all worth gold, regardless of what software they put on top of all that iron? Going with my previous post on App Engine, it all comes down to the experience we need to discuss.
For Newbies This Means...
People just starting out with Python, web development, or even programming at all have a great opportunity here. They can focus on writing code in a very low-barrier environment and not worry about a lot of the details of deployment and hosting that got in the way before. The river between the Field of Writing Code and the Field of Running Your Website has been reduced to a trickle that can easily be waded across.
Few deny the benefit of the lower barrier here for the uninitiated, but there may be some misplaced valuation. There is more to benefit these individuals than staving off their eventual need to understand how to manage and deploy to their own hosting solution. New developers are in an amazing position that none of the rest of us are privy to: they may go entire careers without knowing how to setup a webserver. This is wonderful. Does it mean they are incapable of it or that we'll get a flood of developers who are less able to perform? I believe we see a change in the way we learn. We're narrowing disciplines and we aren't wasting mental cycles and man hours having every gear understand the entire machine. If you write code well, then learn that and just that. Ignore the rest.
Every coder today knows something about designing, even if they aren't good at it. Anyone who has written a line of code, HTML, or CSS for the web has probably configured a database at some point. We take this as normal and expected, and just rites of passage. We fit ourselves into specialties as we gain experience in our niche, but we all have an expectation of knowing a little about a lot. We seem adverse to the idea that the next generate will know how to do their job well, and not at all the jobs we know, but don't do on a regular basis.
For Experienced Hobbyists This Means...
Even when a developer reaches the point that hosting things themselves, managing servers, and configuring databases is feasible, none of it is necessarily worth the effort. All of that is time that could be spent solving the real problem at hand, with your family, or on your real job. The ability to do something doesn't negate the cost in time and effort of doing it. Being able to handle a problem when it arises does not make it meaningless to avoid the possibility of that adversity in the first place.
For Serious Ventures This Means...
With the flood of tiny little apps being launched on App Engine, the question of a large scale app being unrolled on the platform is a big one. Will anyone really build businesses hosted on App Engine? Can Google be trusted with your code? Will this platform offer the real power and opportunity needed to meet the demands of a growing business? None of these are particularly interesting to me in this context, because the deeper question is if the benefits that work for tinkerers and hobbyists extends to "serious" work. I think it does.
Sunday, October 26, 2008
In Part 1 I wrote about my method of testing the actual tag function for a custom Django template tag. I said I would follow it with a Part 2 on testing the rendering of the resulting Node. This is that follow up post for any of you who were waiting for it.
This is an index of different articles I've written covering techniques for testing specific software components. The number is small, but will grow in time. Initially, expect a heavier lean towards Django topics.
Saturday, October 25, 2008
I'm involved in a project that has gone for a long time without tests and everyone involved knows tests are rilly rilly important. There is a point where acknowledged best practices simply meets the reality of the development mind and it doesn't always work out like you'd hope. We know tests are important, but we need to resolve this ticket right freaking now. You understand. The point was reached that this just couldn't continue and the costs of fixing the same bugs over and over were way too obvious to ignore. Tests are now popping up for things we're fixing and new things we're writing. As it happens, I came across my first real need to create a custom template tag. Of course, I wanted to test it. So how do you test something that is so entrenched in the Django processing pipeline as a template tag?
token = Mock(methods=['split_contents'])
Monday, October 20, 2008
So, this was going to be a post about the Python module, subprocess. I'm a big fan of subprocess and there are a lot of problems that are easier to solve by using it. We reduce thirteen distinct facilities into one class. We reduce a diverse ecosystem of interfaces into one, uniform interface. The subprocess module is good, both by itself and as a symbol for what Python stands for. I won't be writing my original post about subprocess.
Saturday, October 18, 2008
We learn to recognize a bad bit of code quickly as our code-fu grows. Arbitrary side-effects smell badly and crazy one-liners frustrate us. It becomes easier to identify what lines of a codebase you might want to clean up to improve the overall quality of the work.
- ► 2012 (19)
- ► 2011 (19)
- ► 2010 (32)
- How To Call It A Day
- How To Backport Multiprocessing to 2.4 and 2.5
- How To Review Memiary in 5 Easy Steps
- How to Underestimate Google App Engine
- How To Test Django Template Tags - Part 2
- How To Test
- How To Test Django Template Tags - Part 1
- How To Limit Your Possibilities
- How To Recognize a Bad Codebase
- ▼ October (9)
- ► 2007 (113)