www.thoughtworks.com aggregator

Brian Oxley: Type Theory for the Uninitiated

Fri, 03 Feb 2012 12:17:00 -0800

Kalani Thielen presents The Algebra of Data, and the Calculus of Mutation, or Type Theory for the Uninitiated. Fine calculus a bit soft, algebra a little dull, programming a walk in the park? Type theory is for you.

Obie Fernandez: Can I Find an Agile, Design-Savvy iPhone Developer?

Fri, 03 Feb 2012 11:00:31 -0800

DueProps has been needing an iPhone app for for a few months now. However, I don't have the time (or frankly, the inclination) to prepare a detailed specification for how it should work. I also lack tens of thousands of dollars to give to an agency to take care of it for me. The last few times I've searched for the right candidate it's been pure frustration.

If I could wave a magic wand to produce my ideal iphone developer, I'd conjure someone who:

...could start to come up with a workable design for the app after spending a few hours talking to me and familiarizing themselves with the way that DueProps works
Understands iterative development. I don't need the app to be perfect or include all possible functionality all at once. The core of what I need is super simple. Login. Choose a prop. Give it to a colleague on your DueProps network or to a new user via their email address. View latest activity. The backend for all that is already there.
Speaks fluent English
Works independent (of an agency) for a reasonable hourly rate, say $30-50/hour

Does such a person exist? I can't be the only person wondering...

EDIT: If the rates I mentioned are too low and a proper rate for (as one commenter put it) a "multi-faceted pro" freelance is more like $100/hour then is it possible to get a simple, finished product in 2-3 weeks at most? Because otherwise it's seriously blowing my budget.

I guess I could approach this as wanting a fixed-bid contract for my budget amount, which is $10-15k, but fixed bids have always scared the hell out of me.

Trisha Gee: Upcoming speaking events

Tue, 31 Jan 2012 23:43:00 -0800

In theory, I am busy writing material for my upcoming speaking events, rather than writing terribly illuminating posts on my blog (see what I did there?). In actuality I am being lazy and have pretty much taken January off for a recharge.

In the spirit of doing something which ticks both the event-speaking and blogging boxes, this is a quick update on the conferences I'm confirmed for so far. Put the following dates in your diary - these are my first international solo speaking events:

7th March - QCon London - Concurrent Programming Using The Disruptor (sadly I can't stay for the whole conference as it clashes with the only holiday I had booked for 2012).
23rd May - GOTO Copenhagen - Concurrent Programming Using The Disruptor & War Stories.
25-26th May - GOTO Amsterdam - Concurrent Programming Using The Disruptor.

The presentation will be more of a user's guide to the Disruptor than anything we've done before. An hour isn't a lot of time to cover all the functionality everyone might want to see, so I'm still trying to work out the balance between giving an introduction/overview for those who haven't seen it before, and going into some of the cool features that have been added since I first started blogging about it. If there's anything you would particularly like to see covered, let me know - I'll put the most frequently requested things in there.

Ideally I'd run a workshop session at some point, but that will require quite a lot more preparation, so I'll only do that if there is interest in it (if someone wants to fly me somewhere interesting to do that so much the better!!).

Maybe I'll see you at one of these events?

Ozgur Tumer: A grand entrance, début of Language Processor

Tue, 31 Jan 2012 05:36:00 -0800

Loaded like a freight train, flyin' like an aeroplane, feelin' like a space brain...

It is the début of Language Processor(LP), my lovely java DSL framework. It is a grand entrance.

We (my esteemed colleague Dr. Daniel Spooner and our team of geniuses) have designed a language for a real time, ticking risk engine. Hundreds of thousand of rows of data is pushed through hundreds of transformations every few seconds. You can join streams of data, create and calculate fields, aggregate rows, split and union data flow.

With our dsl, you can define data sources, define functions, extend data sources, aggregate data, filter, union and much more. Below is a glimpse of what can be done. The language has a proper type system with types like int, boolean, string, real etc. and type inference.

Entire business logic of how data is joined/merged/aggregated is in external files, which are converted to Java on the fly and compiled.

Result is an ultra-fast and compact system, a perfect show-case for a DSL.

We also generate graphs of transformations from the same language files. So it is also self-documenting. An eclipse plug-in is on the way, so is an optimising compiler.

How cool is that!Check this out;

/* define a table where you feed the data in */
let Products = table [

Instrument as "" /*String type */

Underlying as ""

Calculate as ""

Source as ""

ProductUpdated as 01/01/11 00:00:00 GMT /* date type */
Model as ""
]

/* define a function */
let isSimpleInstrument = defunc(instrument underlying model calculate) /* not a derived or calculated instrument */
(and (eq instrument underlying)
(or or (eq "COMPOSITE" model) (eq "COMPOSITE2" model)
(and (or (eq "STOCK" model) (eq "stock" model)) (not (eq "C" calculate)))))

/* extend tables with calculations, you can get the result of any transformation */
let ExtendProduct = extend Products with [
IsSimpleInstrument as isSimpleInstrument(Instrument Underlying Model Calculate)
/* type interference; as Instrument and Underlying are both strings so is the derived field Underlying. */
Underlying as (if IsSimpleInstrument Instrument Underlying)
]

let Prices = table [
Instrument as ""
PriceSource as ""
RIC as ""
Currency as ""
Price as 0.0 /* real type */
PriceTimestamp as 01/01/11 00:00:00 GMT
ReutersLast as 0.0
ReutersClose as 0.0
ReutersBid as 0.0
ReutersAsk as 0.0
]

/* join tables */
let PriceProductJoin = join ExtendProduct with Prices on (eq Underlying Instrument)

Obie Fernandez: Rendering Collections of Heterogeneous Objects in Rails 3.2

Mon, 30 Jan 2012 16:13:27 -0800

This commit by Grant Hutchins & Peter Jaros back in July 2011 gives ActiveModels the ability to define their own partial paths by implementing a to_partial_path method. (You can find a great explanation of this killer new feature on José Valim's blog post about it. Just scroll down to #4 Custom Partial Paths.)

I'm blogging about it here, because it impacts a technique that I described in May 2011 as Rendering Heterogeneous Collections of Objects in Rails. If you happen to be using that technique or anything like it involving the use of ActiveModel's partial_path method, you'll get deprecation warnings like this when upgrading to Rails 3.2:

DEPRECATION WARNING: partial_path is deprecated and will be removed from Rails 3.2 (ActiveModel::Name#partial_path is deprecated. Call #to_partial_path on model instances directly instead.). (called from partial_path at .../config/initializers/partial_path.rb:12)

In this blog post I describe how to update my technique and get rid of the deprecation warning.

The heterogeneous aspect of my technique had to do with rendering collections of STI objects that all inherited from a single Event base class. For organizational reasons, I wanted to put all my disparate event partials in a single app/view/events directory. Without the hack, they'd need to be in their own view/foo_events/_foo_event.html.erb partials. Ugh.

In Rails 3.2, instead of having to monkey patch the framework to fix that crap, I can just implement to_partial_path on the Event base class like this:

class Event

def to_partial_path
"events/#{self.class.name.underscore}"
end

end

Ahh, that's much cleaner. Unfortunately, there's still a catch, but only if you use controller namespaces.

Rails 3.2 keeps the annoying merge of the namespace prefix as part of the generated partial path even if you override it using to_partial_path. The good news is that it is easier to get rid of it in Rails 3.2 than before. The monkeypatch in my earlier blog post now becomes:

ActionView::PartialRenderer.class_eval do

private

def merge_prefix_into_object_path(pfx, path)
path
end

end

What this little bit of duck punching does is to ensure that when you try to render a collection of objects, it will always return the same partial path regardless of whether you are inside a controller namespace or not. I feel that behavior should be default or at least optional (which is why I describe the feature as annoying.) Let me know if you think it's worth submitting a patch.

Incidentally, in his blog post mentioned above Jose mentions needing to add an as: parameter to your call to render, like this:

render :partial => @activities, :as => :activity

In my testing and examination of the underlying Rails code, it is clear that the :as option is not necessary. The PartialRenderer object always checks for the existence of a to_partial_path method on the object being rendered and calls it if present.

One more thing. Currently the documentation states the following (italics mine):

Instead of explicitly naming the location of a partial, you can also let PartialRenderer do the work and pick the proper path by checking `to_proper_path` method. If the object passed to render is a collection, all objects must return the same path.

I'm not quite sure why it says that all objects must return the same path, or why that would even be considered desirable behavior (it's really not!) The good news is that I can verify for you that it does work to return different partial paths within the collection, in other words, you can still do the rendering heterogeneous objects trick. In fact, depending on your naming convention, you may even get correctly name local variables in your partial for free.

The following method determines what to call your partial's automatic local variable corresponding to the current item of the collection being rendered:

def retrieve_variable(path)
variable =
@options[:as].try(:to_sym) || path[%r'_?(\w+)(\.\w+)*$', 1].to_sym

variable_counter = :"#{variable}_counter" if @collection
[variable, variable_counter]
end

That regex is a little tricky, but whether it's the intentional behavior or not, it's going to grab whatever is between the last underscore of your partial name and the dot to use as the variable name. In the case of my own Event hierarchy, that means each partial will get its own event local variable, even though the partials are named _user_created_event, _nomination_event, etc.

Perfect. Now to hope someone doesn't fuck it up in a future release thinking it's a bug :)

Elizabeth Keogh: The Real Cost of Change

Mon, 30 Jan 2012 04:37:42 -0800

We have a strange desire for control.

I was in a planning meeting with my project manager and several of the devs. “What happened?” the project manager said. “Why did this one story take so long?”

“There was some functionality we needed and didn’t know about,” I replied. “We managed to get it in before the deadline, though.” The business had been quite happy with that, and they were notoriously hard to please.

“If they’re going to change their mind like this,” the PM replied, “we’re going to have to introduce some kind of change control.”

“Please don’t,” I begged. “If you do that, the business will spend more time investing in getting things right to start with.”

“Exactly.”

“But they’ll still get it wrong. No amount of planning would have spotted that missing piece before we showed it to them! When they get it wrong now, though, they’ll encounter the change control and they’ll want to spend even more time getting it right first time. And they’ll still get it wrong, but now we’ll have made it more expensive for them to be wrong. We’ll have a formal process which means it takes even longer for us to find out what’s missing, by which time us devs will have to work to remember the code and the change will take longer. It will slow us down. So they’ll see that, and spend even more time trying to get it right, and before you know it they’ll be planning whole projects up front.”

We have a word for that. It’s called Waterfall.

That desire to control change creates a reinforcing feedback loop, in which the cost of change makes us want to invest up-front, which makes the change expensive later on, which makes us want to invest up-front, and so on.

In this case, it would have been pointless, except as a way of shifting blame and risk back to the analysts (and this was an internal project). The cost of change was quite low; we had clean code with a good suite of tests. It was only the cost of discovery, and the implementation that followed, that was really expensive.

Don’t confuse the cost of discovery with the cost of change.

Discovering something later on only costs more than planning for it if you’ve made a commitment to something else.

In fact, if you don’t plan for it, it can cost less. The newly-discovered knowledge will be fresh in everyone’s minds. Because the ideas haven’t been known for long, nobody’s mentally committed to them either, which makes them easier to question and clarify.

This is even more important when there’s a chance that the analysis might be wrong (and there’s always that chance; we learnt this from Waterfall). If you plan for something that you later have to revert, you’ve introduced a cost of change right there. Perhaps the cost is just changing some documents. Perhaps the developers have designed for the plan, and built on top of the thing which needs changing.

But we need to do some planning, right? Otherwise the chances of us being wrong and building on top of the wrong thing are even bigger, and there’s even more chance that we’ll have made commitments the wrong way. So how should we plan?

I’ve got few more guidelines I’d like to share. Here’s the first:

Keep the cost of change low.

This is more important even than planning, because there’s always a chance that we’ll get something wrong.

This is what we’re aiming for: the ideal, low cost of change on an Agile project.

The first thing to notice about this is that the cost of change is not zero. That’s going to become important in the next section, and it’s what drives the team’s desire for change control and starts kicking off that Waterfall loop.

The second thing to notice is that this bears little resemblance to actual, real Agile projects.

On a real Agile project, it’s likely that we have fluctuating levels of stress, concentration, experience and desire for feedback. All of these – or lack of them – will lead us to occasionally write code that is, shall we say, less than ideal.

It takes discipline to write code that’s easy to change. On a real Agile project, we tend not to do it all the time. Oh, we might say we do, but we don’t. Not always. And if we do, our team-mates don’t. The real skill isn’t in writing clean code – it’s in cleaning up the horrible mess we made the week before. And it takes even more discipline to do it afterwards, especially if you’re under pressure to just hack the next working thing in too.

If we don’t clean up and keep that cost of change low, we’re making a commitment to the wrong thing. The longer that commitment stays in place, the higher the cost of change will become. We’ll find ourselves on that Waterfall cost of change curve, and the longer we’re on it, the more expensive it is.

I’ve found the skill to clean up afterwards is even more important in high-learning projects, where a lot of the technology or domain is new, at least to the team. There’s no point in writing tests up front for a class when you don’t even know what’s possible, or what other frameworks and libraries will do for you, or what the business really want. In those environments, rather than TDD or BDD, teams tend to Spike and Stabilize. The spikes aren’t really prototypes – they’re small pieces of features, often with hard-coded data behind them, designed to get some feedback about techology or requirements. Dan North, who gave me the term, might write more about this later if we ask nicely, but for this post, we can simply bear in mind that the skill to stabilize later – ensuring that the cost of change is lowered – is often more important than the skill to keep the cost of change low up-front.

Because we get it wrong too.

Assume you got it wrong.

Human beings are hard-wired to try and get things right, and to pretend that they did even when they didn’t. I love this list of cognitive biases on Wikipedia. These are just some of the ways in which we get it wrong and don’t even notice.

If we assume that we got it wrong, then we start to look for feedback, and quickly. This is difficult for most human beings. We much prefer to get validation than feedback; to be told that we did it right, rather than finding out what we did wrong. Our brain gives us these little kicks of nice chemicals when we learn that we did something right, and it feels much better than the other kind.

If we can remember, though, that we probably got it wrong, our focus will change. Instead of trying to invest in good requirements and nice code, we’ll try to find out what we got wrong in the things we’ve already done. Of course, we need to invest in stabilizing what we’ve done, or the cost of change goes up, and that will make it more expensive later if we find out we were wrong, which is the assumption we were trying to make in the first place… ah, the paradox!

There’s a fine balance to be struck between getting quick feedback – often itself an expensive proposition, given the business of most domain experts – and getting it right up front. So where does the balance lie?

Don’t sweat the petty stuff.

If it’s easy to change, don’t worry about it. Analysts, learn what’s easy to change. Typos, colours, fonts, labels, sizes, placement on the screen, tab order, an extra field… these are all usually easy to change, and do not normally need to be specified up-front. Even if you have a particular style you want to see on a page or form, this can usually be abstracted out and changed later – just let the devs know that you want that consistency at some point.

It’s more important for us to know the rough shape of what you want to see, and the flow and process of that information. We don’t want to know every field on an order item. We just want to know that it needs to be sent to the warehouse and stored locally because you’re going to check the money in the till and count the stock. The fine detail of that is pretty easy to change, so we can get feedback on it later. Getting the fine detail right would definitely be an investment, and we might have got the big picture wrong.

Deliberately discover things you’ve never done before.

Dan North wrote an excellent post on Deliberate Discovery, and I’ve been using it to manage risk on my projects for a while now. It’s one of the most important tools in my toolbox, along with Real Options to which it’s strongly related, so I want to cover how I use it here.

I really like using Cynefin to help me work out what to target for discovery. We treat a lot of software as if it’s complex, and we talk about self-organising teams and high learning environments, but in reality there are huge chunks in most applications which follow well-established rules, have been done a thousand times before and probably have libraries or third-party apps to do the job for you. They’re not complex. They’re complicated. They require the application of a bit of expertise, and are likely to be done right and never changed again. User registration and logging in are great examples of this. You don’t need a big, thick document to describe them. The fine details might change, of course, but we already know not to sweat the petty stuff.

It is OK to plan some aspects of a system as if it’s Waterfall – for instance, deciding up-front whether you want to use your own login or let Google authenticate. Even better than requirements documents, and quicker, is to say, “It’s user registration. Make it work like Twitter’s, but we also need the user’s loyalty card number. We should offer to send them a card if they don’t have one.” Dan North calls this pattern “Ginger Cake” – it’s like a chocolate cake, but with ginger. He even cuts and pastes code. And it’s OK! Honestly, it is! This code is also absolutely prime for TDDing – if you actually have to write it yourself, that is, since it’s been done before so someone’s probably written something to do it for you already. You can also give this code to junior devs, for whom it’s new, and guide them in TDDing, making it perfect pair-programming territory. Everything you have ever been told about Agile software development applies particularly in this place.

Fortunately, most applications have a minimum set of requirements that they share with other, similar applications. David Anderson calls these commodities – table stakes that you have to have just to play the game – so *most* code in an application will end up going this way.

The places in which we’re most likely to get it wrong, and need fast feedback, are places where we’re doing something new. They might be technological, particular to a domain, or just things that the team themselves have never looked at. My favourite book for understanding risk is “Waltzing with Bears”, which starts the first chapter with, “If a project has no risks, don’t do it.” It’s these new, risky aspects of the project that differentiate it from others and make it valuable in the first place!

For new and risky aspects of a project, the best thing to do is assume you got it wrong, and work out how quickly you can get feedback on how wrong you are.

Any new or unknown aspect of a project will need to be changed.

I was chatting to one of our analysts. “I can see this feature is in analysis at the moment,” I said. “Does that mean it’s the next thing we want the developers to do?”

“Oh, no,” the analyst said. “It’s only there because the analysis is quite complex. It’s all new stuff, so we’re having to be careful with it and it’s taking a bit of time. Once we get the analysis done, the development should be very easy, so we’ll do it later.”

“Oh, the development will be easy, I’m sure… but wouldn’t you like to find out what you did wrong now, rather than later, while it’s still fresh in your mind?”

The analyst smiled. The company was very much more used to Waterfall, and the idea that it was OK to get it wrong was something very new.

It’s OK to get it wrong, as long as you get feedback quickly, while the cost of change is still low. By working out which parts of a project are unknown or new, and targeting those first, we make small investments while the cost of change is still low.

Keep your options open – do the risky stuff first and keep tech debt low.

Anyone who’s run into me at conferences will know how much I love Real Options, and it’s really at the heart of the cost of change.

The only reason change costs more is because of the commitment that we already made. Chris Matts describes technical debt as an “unhedged call option”. He says, “You give someone the right to buy Chocolate Santas from you at 30 cents each. That’s fine, as long as the price of chocolate stays low. As soon as it goes up, you still have to pay to make the Santas, and now you’re in trouble and your company is going bust, because you didn’t give yourself the option to get the chocolate somewhere else.”

Similarly, technical debt is absolutely fine until we’re called on to act, and act fast. At that point, we’re in trouble. This is the biggest reason for keeping the cost of change low – because it gives us the option for change, later. It’s a frequently-cited reason for replacing legacy projects – and, bizarrely, often forgotten when the pressure mounts and the business want their replacement app.

This isn’t helped by common practices of estimation and the associated promises, which often lead to that pressure building up in the first place. Rather than making these promises up-front, why not try the risky bits first? I often hard-code data so that I can get feedback on a new UI early, or I spike something out using a new library or framework, or connect to that third-party application just to see what the API is really like to use, or have a chat with the team writing that other system we’re going to need in June, so I can find out how communicative and receptive to feedback they are. Doing this means that we give ourselves the most time to recover from any unexpected discoveries, and we can worry about the more predictable aspects of a system later.

Once we’ve got spikes out of the way, adding tests to act as documentation and examples for any legacy code we’ve created, cleaning it up so it’s self-commenting, ensuring that architectural and modular components are properly decoupled, etc., all help us to stabilize the code. At the same time, the effort involved in creating stable code is itself an investment. If there’s a good chance that the code might be wrong, it could be worth getting feedback on that – knocking up integration tests, showing it to the business, testing it, getting it live – before it’s made stable.

That way, the commitment made is small, and the cost of change is low.

Just remember to clean up and keep it that way!

Update: Dan is currently writing about Spike and Stabilize and Ginger Cake as part of his “Patterns of Effective Delivery”. If you’re interested in finding out more, you might like to watch his Roots talk on the topics.

Ted Neward: Top Developer Resources?

Sat, 28 Jan 2012 02:03:48 -0800

While going through some spam email (well, technically not spam, since I willingly signed up for the ads/product-centric-newsletters, but that is just a mouthful to say), I ran across the App Design Vault 32 Top Resources Mobile App Developers Should Know About list, and had a look. I was somewhat disappointed at the fact that they were all iOS resources, leaving the Android and Windows Phone crowd out in the cold, not to mention Java, .NET, Ruby, and others shivering on the back porch as well.

So, I figured, why not build one that seeks to be a tad more all-encompassing? And rather than try and impose my own sense of order upon the world, and limit it to my own experiences, I choose instead to crowdsource the thing, and let you tell me what you think the top developer resources are.

Because these things have to have some kind of structure, in order to effectively collate all the resources that will be thrown at me, I’m going to ask that you

Limit your list to five resources. The final list will likely (I hope) contain a lot more, but if you just give me the top five resources you think are invaluable to you as a developer, it’ll make the list more well-considered and pare it down to just the essential stuff you think about.
Keep the lists somewhat tech-focused. Not in the sense that I don’t want to know about agile resources and what-not, but that I want to hear what your top .NET five are, your top Java five, and so on. Of course, if you really want to just come up with one list across several platforms or categories, go for it. Yours is the comment box, after all. :-)

And if you work for a company or you own a product, please feel free to nominate your tool of choice… so long as there are four others that go along with your baby. Fair is fair, after all. ;-)

And yes, for those who are curious, I will of course inject my own into the list, but I just had this thought latch into my head a few minutes ago, and haven’t compiled my own list yet, so I need a little time to think about it, too.

Roughly speaking, categories that come to mind are: .NET, Java (which I’m assuming to mean mostly enterprise/Java-web kinds of things, but hey, if Swing is your thing, go for it…), Ruby, Web, Game development (any platform), Android, iOS, MacOS, C++ (by which I really mean “any language that compiles to native code”, a la Haskell, C, Delphi, …), and what the hell, PHP. (Perl guys, I’m going to automatically put “Any book teaching some other language” at #1 on your list, just to tweak your nose a bit.) If you have some other categorization, sure, throw that at me, too.

The App Design Vault broke their resources down into a few categories too: Books, Tutorials, Tools, Sites, Forums, Marketing, and Design. Obviously there’s a pretty strong website bias in there (Tutorials, Sites, Forums, Marketing and Design all usually involve websites of one form or another), but feel free to toss in Conferences, Magazines, and whatever else seems useful to you.

Think of it like this: if a programmer writing an app for you were to be stuck on a deserted island with nothing but a laptop and an extremely limited Internet connection, what five things would you want him/her to have with them or access to? (Perhaps more accurately, “a fully-available Internet connection but a very limited amount of time to do anything other than work on your app” is the better way to phrase that...)

And please, no flames or criticism of anybody else’s list. Email ‘em to me, if you’d prefer. (And if you’re reading this through one of the post portals—a la Reddit or DZone—please comment on the original site, tedneward.com, or I probably won’t see your comments.)

Once I have what feels like a sizable list and the suggestions are tapering off, I’ll update this post with the results. No points or awards or endorsements intended—I just want to compile something I think would be useful.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Joshua Graham: Viewing full Facebook site on mobile device

Thu, 26 Jan 2012 20:50:43 -0800

A plethora of useless answers out there. Here it is:

On an iOS device

Scroll page so you go past the top of the Facebook page and can see the browser address bar
Change the m to www
Remove the ?_rdr#~!/
Press Go

You may have some fiddling to get the auto-appearing drop down tools on posts but they will come.

Enjoy.

Ted Neward: When are servers not servers?

Wed, 25 Jan 2012 15:45:33 -0800

In his Dr Dobb’s overview, Andrew Binstock talks about the prevalence of low-cost, low-powers and suggest in the title of the piece that they have begun their steady ascent over more traditional servers. His concluding statement, in fact, suggests that they will replace the “pizza box” servers we have come to know and love.

Ironically, to me, the notion of a “server” still conjures up images of row upon row of full-tower machines, whirring away. In fact, I have one of those under my work desk at home, doing… nothing. Right now I have it more or less permanently switched off.

Andrew and I have disagreed on things before, but on this score, he’s right: the machines we commonly call “servers” are, step by step, slowly but surely, becoming smaller, quieter, lighter, better power-friendly, and all the other things we have traditionally associated with the client side of the client/server equation. It’s not new: I have a couple of friends who, in order to do “cloud” or “cluster” presentations, carry around with them a small private cloud. One of them carries around (as in, with them to conferences and such) about a half-dozen laptops, the other, a custom-made rack of Mac Minis, a router, and other accoutrements. Yes, if you attend TechEd, you probably know exactly whom I mean.

But this raises some interesting questions. If servers are becoming smaller and lighter and are still fast enough to be considered servers, what does this have to say about infrastructure? Andrew touches on it briefly,

This model of low-cost, low-power devices is the way of the future. What I am describing here is not terribly different than building your own personal cloud from inexpensive machines. If you had chosen to keep the $300, you could have gotten this much from Rackspace's cloud server: 512MB RAM and 20GB HDD running Linux. That's not close to as much horsepower as my machine delivers However, it gives you two advantages: You have no additional ongoing costs (power consumption, parts replacement), and because it's off site, you have an instant off-site backup of your code base. Other companies, such as IntoVPS.com, give you about twice Rackspace's resources for the same price. Eventually, the pricing of cloud options will drop to close to the low-power, on-site devices, I expect. (Source: http://drdobbs.com/tools/232500406?cid=DDJ_nl_mdev_2012-01-25_h&elq=5c23117c5cff4d06820726bd0294693a)

… but putting the discussion of “on-premise” vs “cloud” off to one side for a moment, it raises a more interesting question: if servers are small enough to carry around with us, are they still servers? Historically, the server has always been the machine in the data center, but if we have tools that allow servers to synchronize data between them easily (such as we see going on in tools like Dropbox or Evernote), and the servers are small and portable enough to fit in our pockets, then are they still servers?

Think about this for a moment: the servers that Andrew describes (“a 1.8GHz dual-core Intel Atom chip, 2GB RAM, 250 GB SATA, HDMI, 6 ea. USB, Wifi, and GbE” and “a dual-core 1GHz ARM-based Tegra chip from Nvidia, had robust Nvidia graphics (HDMI), 1GB RAM, a 32GB SSD or a large capacity HDD, and all the USB and other ports you could possibly want”) are hardly the heavy-metal monsters we used to think about when discussing “servers”, and yet still serve the purpose. If we don’t need the server for its processing power, and if we don’t need it for its central location (as a rendezvous point for clients to discover each other and/or centralize data), then what purpose does the server serve?

Maybe it’s time to take a really hard look again into those peer-to-peer ideas from about a half-decade ago.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Ted Neward: Is Programming Less Exciting Today?

Wed, 25 Jan 2012 15:24:43 -0800

As discriminatory as this is going to sound, this one is for the old-timers. If you started programming after the turn of the milennium, I don’t know if you’re going to be able to follow the trend of this post—not out of any serious deficiency on your part, hardly that. But I think this is something only the old-timers are going to identify with. (And thus, do I alienate probably 80% of my readership, but so be it.)

Is it me, or is programming just less interesting today than it was two decades ago?

By all means, shake your smartphones and other mobile devices at me and say, “Dude, how can you say that?”, but in many ways programming for Android and iOS reminds me of programming for Windows and Mac OS two decades ago. HTML 5 and JavaScript remind me of ten years ago, the first time HTML and JavaScript came around. The discussions around programming languages remind me of the discussions around C++. The discussions around NoSQL remind me of the arguments both for and against relational databases. It all feels like we’ve been here before, with only the names having changed.

Don’t get me wrong—if any of you comment on the differences between HTML 5 now and HTML 3.2 then, or the degree of the various browser companies agreeing to the standard today against the “browser wars” of a decade ago, I’ll agree with you. This isn’t so much of a rational and logical discussion as it is an emotive and intuitive one. It just feels similar.

To be honest, I get this sense that across the entire industry right now, there’s a sort of malaise, a general sort of “Bah, nothing really all that new is going on anymore”. NoSQL is re-introducing storage ideas that had been around before but were discarded (perhaps injudiciously and too quickly) in favor of the relational model. Functional languages have obviously been in place since the 50’s (in Lisp). And so on.

More importantly, look at the Java community: what truly innovative ideas have emerged here in the last five years? Every new open-source project or commercial endeavor either seems to be a refinement of an idea before it (how many different times are we going to create a new Web framework, guys?) or an attempt to leverage an idea coming from somewhere else (be it from .NET or from Ruby or from JavaScript or….). With the upcoming .NET 4.5 release and Windows 8, Microsoft is holding out very little “new and exciting” bits for the community to invest emotionally in: we hear about “async” in C# 5 (something that F# has had already, thank you), and of course there is WinRT (another platform or virtual machine… sort of), and… well, honestly, didn’t we just do this a decade ago? Where is the WCFs, the WPFs, the Silverlights, the things that would get us fired up? Hell, even a new approach to data access might stir some excitement. Node.js feels like an attempt to reinvent the app server, but if you look back far enough you see that the app server itself was reinvented once (in the Java world) in Spring and other lightweight frameworks, and before that by people who actually thought to write their own web servers in straight Java. (And, for the record, the whole event-driven I/O thing is something that’s been done in both Java and .NET a long time before now.)

And as much as this is going to probably just throw fat on the fire, all the excitement around JavaScript as a language reminds me of the excitement about Ruby as a language. Does nobody remember that Sun did this once already, with Phobos? Or that Netscape did this with LiveScript? JavaScript on the server end is not new, folks. It’s just new to the people who’d never seen it before.

In years past, there has always seemed to be something deeper, something more exciting and more innovative that drives the industry in strange ways. Artificial Intelligence was one such thing: the search to try and bring computers to a state of human-like sentience drove a lot of interesting ideas and concepts forward, but over the last decade or two, AI seems to have lost almost all of its luster and momentum. User interfaces—specifically, GUIs—were another force for a while, until GUIs got to the point where they were so common and so deeply rooted in their chosen pasts (the single-button of the Mac, the menubar-per-window of Windows, etc) that they left themselves so little room for maneuver. At least this is one area where Microsoft is (maybe) putting the fatted sacred cow to the butcher’s knife, with their Metro UI moves in Windows 8… but only up to a point.

Maybe I’m just old and tired and should hang up my keyboard and go take up farming, then go retire to my front porch’s rocking chair and practice my Hey you kids! Getoffamylawn! or something. But before you dismiss me entirely, do me a favor and tell me: what gets you excited these days? If you’ve been programming for twenty years, what about the industry today gets your blood moving and your mind sharpened?

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.