You have an iPhone, without a phone plan?

"You have an iPhone, without a phone plan?"
"Why, yes I do"

I guess if there is one nice thing about having a first gen iPhone, it was relatively easy to buy one and never sign up for a two year contract.

Why??

I think of the iPhone like an iPod Touch but with: Camera, Mic, Speaker, External volume control, bluetooth. Oh, and it happens to be a phone, if you want to use it for that.

So what applications does this non-phone iPhone user use?

WeDict
If there was one application I would of predicted these would be twenty of on the day of launch, it was a dictionary application. There where two, one costs $29.99, the other is free and is just fine.

Stanza
Reading a book on the small iPhone screen seems intuitively doomed to awkwardness. I have been reading one of the supplied eBooks for the last three evenings without any discomfort at all.

Jott
If there is one application that has intrigued and frustrated me this is it. You talk, it record, sends to server, transcribes and sends back. Makes we want Dragon Dictate for the iPhone, also makes me want copy and paste.

Dobot Todos
There a quite a few TODO apps, this one is adequate, it breaks from the application norms by instead of deleting an item by "edit"->"click on minus sign"->"select delete" it just wants a swipe across the offending row and a "select delete".

AccuFuel
I want to prove to the world (well Dan who has a hybrid) that I can regularly get 42mpg in my car.

Tap Tap Revenge
If I want to show off what the iPhone is capable of, this is the app I fire up, and then challenge to a "Tap off" (and CRUSH, yes Rachana I'll take you on any day).

Chopper
Game has a nice use of the accelerometer, lean the phone back/forward/left/right.

Phone Saber
Hard for any self respecting X-gen'r not to get this.

Restaurant Nutrition
For the guys that eat fast food in the office, I can instantly see just how bad their food is for them, and inform them of it.

Pandora
Interesting enough to make me look in detail at the Apple licensing agreements to see what they say about streaming music over the cell network, apparently not much. They mention VOIP and not 'burdening the cell network' and that's about it.

Most of programming is routine, and that's a problem.

While coding, I always have this nagging feeling that someone has already done what I'm doing, and done a lot better job of it than I. Heck, its more than a feeling, I just know it! It frustrates me, knowing there is this useful information that could save me time, just beyond my grasp.


At the end of the day I am interested in building programs with interesting functions, that I know about Java or SQL is purely a side effect of creating these interesting programs. If I could get away with knowing a lot less about Java and SQL, I would!


I'm not saying that aren't a lot of benefits from knowing low level systems, I think there is a huge advantage from knowing low level systems well. Just look at Skype, an application that is only so amazingly useful because the creators knew a lot about NAT traversal and P2P networking. But the creators of Skype also had to program a lot of routine things as well, things that ARE well understood, and that is where the wasted effort is.


If only we could spend a majority of our time working on the things that WEREN'T well understood, the interesting things. The mundane things, well, they are just as mundane to program as well.



This isn't a comment about OO in general, its more a comment about everything we do in software development in particular.


There are lots of things we (software developers) do, that are well understood:

1. If you need data for twelve rows of data, don't do twelve queries to get the data, do one.
2. When displaying read only data, no need to marshal all the objects, just load the relevant data.
3. In Swing programming don't do long running operations on the AWT-EventQueue thread.
4. Etc...


There are many rules that people apply for each situation that arises. The frustrating part is that when you encounter a new technology/framework you have to discover all of these rules of thumb, even though chances are that you are walking down well trodden path.


To me a great example is the email lists, where 90% of the time people are asking about the same 10 things. This is how the FAQ was born. But the FAQ has really gone no further, its not in an actionable form, we can't reason with it, we aren't able to programatically derive semantic meaning from it.

So? How do you design a system to have the smarts to know what to do?

Well I promise to post about it as soon as I figure that out :)

Project Euler

Grant has been trying to bully me into writing some Haskell code. The straw that broke the camel's back was the challenge to solve "Project Euler: Problem 1", well really the problem was not that interesting, but we had a good spread of languages in the office everyone wanted to solve the problem in, so this is a fun opportunity to compare writing the solution in our own pet languages. Grant used Scheme, Geoff: Ruby, Kartik: C++, Dan: Delphi, Chris was out sick, but I bet he'll do it in C#. Me, I'm going to use Haskell.

We had already discussed earlier in the day that there is an equation to give you the sum, but in the spirit of all following the same approach, I won't be using it.

The plan is for everyone to post the implementation in their blog, so without further delay, here is mine:

sum [n | n <- [1..999], mod n 3 == 0 || mod n 5 == 0 ]]

Video Conferencing on a budget.

Holding our monthly company wide meetings have always been problematic, one problem is half the team is in India and the other half in Milwaukee. Other problems include 512kbps bandwidth for the team in India, also the lack of will to spend $10k (per location!) on a Polycom solution.

Having two groups of people in their respective conference rooms and trying to hold a discussion has proven to be very different than sitting in front of your computer, wearing a headset and chatting over Skype. The microphone has problems picking up individuals in the room, the use of external speakers causes horrendous feedback, and the low video resolution that didn't matter before, matters now because we can't make out individuals in the room.

So I was appointed to do a little research into solving this issue. Had I been given a budget of $20,000 it would of been quite a simple job, buy a couple of Polycom systems and be done with it, however my budget was in the 'something reasonable' range.

I decided to try out iChat on the Mac, mainly because I have family in Scotland and Australia and have a lot of experience with using it for video conferencing, and swear by it. The biggest problem with iChat would be firewall configuration, but since we have an inter-office VPN, it's not a problem at all. To make this choice even easier, we already had a Mac Mini in the office in India.

Setting up a test was simply getting Geoff to bring in his MacBook Pro to our next company meeting. Setup was quite painless, we did get a 'insufficient bandwidth' error, but solved that by dialing down the speed from 'unlimited', and then it was up and running.
The results were very positive, the video was by far the best quality we have ever had, nice high resolution, we could see everyone in the room very clearly. The audio was more of a mixed bag, on the up side the feedback/echo was very slight, but on the downside the mic had trouble picking people up in the room and speakers were quiet even with the volume maxed out to ten, I think it's the first time I've really wished that we could turn speakers up to eleven.

Since then I have researched external speaker/microphones and was able to locate a higher end combo made by ClearOne, called the Chat 50, its quite pricey at $130, but if it solves our sound problems it will be worth every penny.

Since the test went so well we will be purchasing a Mac Mini and iSight for the Milwaukee office, and also a Chat 50 to try out.

All in all the total cost will be about $900, with maybe some potential cost savings by getting a refurbished Mac Mini.

Definitely something reasonable.

Differences between meta-programming and intentional programming

In an effort to post something to this blog, here are some current thoughts:


After some reflection I have decided that meta-programming and intentional programming are two very different things.

Meta-programming is just about using/creating custom programming languages. The only intent meta-programming provides is just that which occurs due to the domain specificity of the languages in use. The actual code generated is still very mundane. Nothing special here.

Intentional programming to me means doing much more than just this. To me it is about leveraging the intent as much as is possible. Part of getting the intent is raising the level, and meta-programming is a great way to do this. But intentional programming can be some much more than writing software at different levels.

If intent has been encoded in such a way that we can leverage it, then the possibilities are huge.
For Example:
When about to perform a lower level db query we can, at this point in time, look and see what the higher level intent(s) is. Is the intent to just display this data on the UI? Is the intent to do X with the data?

We seem to have got into this rut of having very low expectations of what we can do, creating static code that's very dumb that doesn't know much. And them doing a huge amount of work to make up for all these deficiencies.

When we (the developer) write the code we are taking into consideration the intent and the implementation of many many layers. But what we create is this code that doesn't know the big picture, and couldn't but help be brittle and prone to errors. Heck a person given three parameters and an algorithm in isolation couldn't do much better either.

IMPLEMENTATION MATTERS contiuned

I was just working with java collections the other day and it got me thinking....

From the JavaDoc:
ArrayList
The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking).

LinkedList
All of the operations perform as could be expected for a doubly-linked list. Operations that index into the list will traverse the list from the begining or the end, whichever is closer to the specified index.



This speaks to my previous comment "Interacting components will not only be able to interface with each other through a well defined contract but also have a conversation about each others implementation details."
Why do we determine what data structures and implementations to use at design time? For a dynamic system this is not really a decision you can make at compile time, becuase (as you can see above) so much of the performance depends on the actual implementation.
Using metadata and metaprogramming we could provide this information along with our module/component/call-it-what-you-will and then the system as a whole can make a call as to what is the best way to format the data for maximum performance.

Same for my games programming / graphics card example, the graphics card can let the calling program know what types of data result in what types of performance, then the system as a whole can determine which way to format which data and even decide at runtime which underlying implementations to use (ArrayList or LinkedList).

IMPLEMENTATION MATTERS

Conventional programming techniques tell us when creating a large software system that we should isolate components from each other using the ‘black box’ technique.

This idea behind this is simple, “why expose all the complexity of the system to third parties?”, instead you can define an abstraction for the complex system and enable interaction through this. Utilizing the abstraction provides us with many advantages; the most relevant advantage is the ability to interact with this component without understanding everything about it.

But the technique of abstracting out a complex system generates problems of it own; problems I believe cripple our ability to move (the engineering of) software forward. The following are some of my thoughts (ramblings) on this:

MONOLITHIC SOFTWARE

We cannot engineer software that doesn’t depend on implementation.

Even though we create systems that may have hundreds or thousands of interactions through approximate interfaces, this software still only works when treated as a single piece of unchanging code.

We can only engineer software we are confident works if at some point of time we lock down all codebase and make it monolithic.

While some systems (like Firefox or Eclipse) do support plug-ins at runtime, these changes are cosmetic at best, these components typically don’t have other (unexpected) components depending on them, these are simply plug-ins at the extremities of the dependency graph.

IMPLICIT CONTRACT

When we work with interfaces, we are really working with the implementation.

The myth is that if we define an interface completely enough, then the implementation doesn’t matter.

However during the development and testing cycles we are testing against an implementation of the contract, and by doing this we really no longer working with a black box system we are working with an implementation, so we are working with a contract implicitly derived from the implementation. This is sometimes referred to as a leaky abstraction.

COMPLETE CONTRACT

There is a way to define a contract so completely that its implementation will be unambiguous.

The only time you can successfully interact with a system without caring what the implementation of a black box, is if the contract is defined so completely that there is no ambiguity in the implementation. The good news is that there is such a contract! The bad news it that this contract is the implementation itself!

Even a logically equivalent implementation would not be sufficient, i.e. code that for every possible combination of inputs would give the same outputs as a different implementation. Since there could be different internal failure points and dependencies.

MINOR FLAWS MILTIPLED

Inconsistencies in implementations create flaws, which become magnified in dynamic systems.

Currently we have no way to create software that can be truly assembled at runtime with differing implementations, because it would just not work.

Imagine if using today’s technology we defined a contract for 100 different components, and all these components interact and leverage each other. We then give these 100 different components to 2 different groups of people to implement, these implementations fulfill the contract.

If we then try to run the system and for each component randomly choose which of the two implementations to use for each component, this system would never work.

SPECIFICATIONS

Speicifcations are just a contract.

Specifications are really another face to the same problem, just another way to try to define a contact without defining the implementation.

A great example of this is the attempt by Sun Microsystems to try to define the J2EE spec to make EJBs vendor neutral. The idea was that you could build an EJB for IBM’s WebSphere Application Server and then you could then deploy it on BEA’s Weblogic Server and it ‘would just work’.

In practice this was simply just not the case, even the hugely increased detail in the subsequent EJB specifications has not made them portable.

INTENTIONAL PROGRAMMING

DSLs have implementations too.

The current metaprogramming technologies also have this problem. A metaprogram is eventually implemented, the DSL itself can and will be implemented in an ambiguous way as well.

However there is good news, capturing intent on many different levels (layers) gives us the potential to have so much more information to work with.

IMPLEMENTATION MATTERS

And it’s ok! We should stop trying to pretend that everything works the same.

Thanks to all this extra information we now have a broader semantic description of a programmer’s intent.

Once we have entire systems written this way, we will then be able to do so much more.

Interacting components will not only be able to interface with each other through a well defined contract but also have a conversation about each others implementation details.

If we think of the optimizations that a game programmer typically does to get high performance rendering, even though the programmer is interacting through a generic interface (like DirectX) she is only able to truly achieve great performance if she knows a lot about the implementation of the graphics card behind the generic API.

While critical to high performance these optimizations are typically not some great insight they are just the application of gained knowledge. There is nothing here that couldn’t be automated, if the graphics card could communicate to the calling program the most performant way to structure its graphics data (texture size, byte alignment, etc…) then this system could be as fast as one coded by hand.

FUTURE

This is what I see in the future thanks to metaprogramming technologies like intentional programming, this will be one of the first times where a new technology will actually be able to run faster that the previous one. Think of a complex system which runs as fast as if it had been completely coded by hand at every level. No only this but also a system that would truly be dynamic, since it would be able to change implementations behind abstractions without the loss of stability or performance.