I've been using Intellij IDEA for years, I pretty much swear by it for development and I have no real complaints. But now I've got a new job and they use Eclipse. Now, so do I. I figure there is no way to properly learn to use Eclipse if my heart is still in IDEA, so there's nothing for it except to say goodbye IDEA and move over to Eclipse for everything. Looking around the Eclipse ecosystem and there are an awful lot of what look to be excellent plugins. I know IDEA had a plugin system but the ecosystem never seemed as good and I never really got into them. Now it's off to import my projects and see what's what. I did try this a few weeks ago after my interview, but gave up with the excuse that I wanted to get some work done.

I'm having a bit of a clear out, taking a look at some of the code I've written and I've been pushing some of the stuff I'm currently using up to GitHub under and Apache 2 licence. I've used things in Announce.ly, Sproozi and some other small projects and figure they may be useful to someone else. My only criteria has been to ask If I'm using it now in a project, if so I'm actively supporting it and I've started pushing that stuff to GitHub, everything else is dormant and I don't want to release something I'm not actively supporting- it also occurs to me that if even I'm not using it, it can't be all that worthwhile. I've just pushed some code I've been testing for a few months in a couple of projects to GitHub. It's an accounts package written for Spring, that ties my oAuth library and Twitter together with either Hibernate or Hbase as backend storage. In it's simplest form when you login with twitter it creates you a new user and persists it and the oAuth access tokens you need to act on behalf of that user. I'll write some more about it, better documentation and probably throw a little more code up on GitHub over the course of the next couple of weeks as and when I get a chance.

I've been working lately trying to implement some of the things Eric Ries talks about. Primarily the idea of continuous deployments for lean startups and getting away from the fear of release. On the surface and looking back on some of the disastrous releases I've seen (deployed) it's a frightening concept. The problem with most of those releases though hasn't so much been that there was a bug or a problem, it was there was no fall back position - the release was made and there was no way to unmake it. Also working in Java releasing WARs has been a pretty big issue - you have to upload the whole release to fix even a small bug like a typo. One bug in these cases can mean you're 15-20 minutes from uploading a fix. It's a very bad place to be and I want to avoid it at all costs in the future, both the problems and as a result the fear of a release. With that in mind I've been fashioning a system for Sproozi where a release is made as an exploded war using Hudson. On commit it's tested, deployed to a single server in the cluster and tested some more. The server joins the main cluster and it's monitored as the release is pushed to the rest of the servers to make sure it's stable. The only problem I'm having conceptually is how do I treat a commit that comes in before a release is finished - I guess I have to sit on it, but what if the release fails and I have to lock the repository? What about if the release is a success but in the meantime I have 2, 3 or even more commits that I'm sitting on? Do I deploy them one at a time until they're either all successful or one fails? How has anyone else practising dealt with these issues?

The thing I really like about Amazon's cloud stuff is they're constantly undermining themselves with new innovations - spot instances are another great example. Taking the utility metaphor a step further you can now rent their services when nobody else is for cheaper, like buying electricity at night. A lot of the tasks I'm envisioning for Sproozi aren't really time dependent. While it's important to show you a page in a timely manner, crawl and index a brand new website you add quickly and basically be interactive there is also a lot I have to do in the background. The huge and growing list of URLs people add all need to be re-crawled and re-indexed regularly is just one of many examples of processing vast amounts of data. These tasks are always running, always in the background. Spot instances are a perfect fit - I can bid the price I want on extra capacity spin up some extra instances to join the cluster when they're cheap. Over the next few weeks I'll probably try to add some spot instances to my Hadoop dev cluster and see what happens.

This is possibly big news, something I've hoped they would do for a long time and something Fred Wilson voiced his support for a few weeks ago: Creating user accounts via the twitter API. Both the projects I'm working on full time could benefit from this. Sproozi of course because we could create user accounts for them and help users find interesting local people to follow. My oft promised side project which at it's most basic level [the one I'll launch first] aims to make making announcements easier could benefit by making the signup process seamless - users wouldn't have to already have to have a twitter account, they could create it all in one step with us. That I think is what makes this such big news, sites that rely on users already having a twitter account to do something useful will be able to create that account as a seamless on site process. That will help drive users to the sites and drive users to twitter. Let's hope they start rolling it out to other developers!

Related articles by Zemanta

• Twitter Extends Sign-Ups Off-Site As It Seeks New Users (mashable.com)

I followed up with a few potential investors who've had my pitch for Sproozi today. It's been a week or two since I heard from them and I honestly wasn't surprised when they came back with a no. Not hearing anything doesn't exactly show a great deal of excitement. I'm an optimist though and on the bright side I haven't had a conversation or a meeting that I haven't benefited from. With first VC I met I had a pretty friendly audience, I knew him already, and I got some really good advice about how aspects of the pitch, the business in general and some introductions. With another, less friendly, it was clear I hadn't done my homework. In yet another I learned a bit more and took on board the suggestion that I get a core set of users together to beta test the project - that basically just launching it blind was probably not going to go anywhere. The rest of my meetings and conversations have been just as good. In each one I've refined my pitch further had clearer and better prepared answers for questions but I think I may be making one mistake that is keeping me from getting funded- trying to0 soon. I'm starting to think that, because I have to explain the idea. I really s to be able to just give someone a link they can click and play with. With a link and 10 minutes, countless objections can be overcome and services that sound similar dismissed - it also gives a pretty clear idea of exactly what the thing does. I can't possibly manage that level of understanding in any pitch, no matter how long or how refined. So what's next? I've got a side project I keep hinting about that's painfully close to ready to launch very soon and then I'm going to keep working on Sproozi, get it to the point where I can send that link, develop some feedback from users and get some interesting data - get it to the point where I'm talking about what we are doing, not what we want to do. I'm not put off, if anything I'm more focused on distilling Sproozi down to the minimum set of features I can launch with. If you haven't already, signup for the super-secret-pre-alpha on the Sproozi site and as soon as I get there, I'll let you know.

I realised that I'm not very good at this when I looked at my last commit for this theme. The message was "added a few things" a message I find myself using when I have nothing else to say, or if I've done too much work and either can't remember all of what I did or be bothered writing it all out. It's bad form though, and I'm trying to learn my way into using git properly to make it happen less. Basically I'm still trying to find the right place between a commit for a unit of work and my previous more traditional view that all commits must compile and pass tests. At the same time I'm trying to reconcile that with a Kanban board way of organising what to do. How does everyone else commit? When, how often and what 'rules' do you apply?

Sproozi is getting closer to actually doing something that's worth showing off. I've setup a blog for it at blog.sproozi.com where I'll post development updates. I've also added beta pre-registration to the Sproozi site. We're going to need testers as soon as it launches, so if you'd like to help out let me know over there.

When: Wednesday November 25th @ 7:00pm Where: Hole in't Wall, Hebden Bridge (map) What: We're holding a GeekUp style meet in Hebden Bridge, open to anyone who is a geeky about anything. There is no formal agenda or presentations planned, we'll see how it goes, hope it works and if it does we can to turn it into a regular event. Most established Geek Ups are primarily aimed at techie geeks - We'd like to see ours better represent the area and to be something unique. So we're throwing the door open to all geeks, if you're obsessive about something (tech, beer, music, films, books, knitting...), come along. Read more about Geek Ups in general at Geek Up. Questions, comments etc direct them at me here, on twitter @andrewmccall or email.

I've had an ongoing conversation with a few people over the course of a few projects about the questions to ask when people sign up on the web or what hoops you make them jump through. Ask most people what they need to know about user's and you'll end up with a list of information from the useful like name to the truly useless like job title or title. Give me one good reason for either. Are you going to be sending Mr John Smith or Dr. Sarah Jones a letter using their formal titles? When it comes to things like Job Title, the reason I usually hear is that it'll be useful for marketing and demographics later. Maybe, but I've never actually seen that later come to anything. So I don't buy it. If the signup form is the depth of your engagement with your user you might as well drop the pretense of a web application and go back to sending newsletters. Just don't do it. Ask your user the bare minimum number of questions you need to get them started using what your product does now and stop throwing up barriers to entry. Aside from just the questions that are asked there are other things, the hoops almost every site makes you jump through before you can start using it. Probably the best example is the ubiquitous confirm your email step. Do we need to be doing this? In some circumstances I'll admit it makes sense, if your delivering content via email for example or signing up for a mailing list. Of course you want to make sure the user wants what you're sending them. But for every other site, I'm not sold. It's just another step they have to take to start using your service and all the little steps all add up to users hating signing up for new things. Also it begs the question, why even bother? For 99% of websites the only reason to make sure a user has entered their email address correctly is so that you can let them recover a password. You're adding the step for people that have lost their password and haven't managed to get their email right. That's going to be a fairly small proportion of your users; even less if you let login with their email address, then they'll know it's wrong anyway as soon as they try it. Do we pander to the idiots or make things as quick and easy for everyone else? I'll take quick an easy any day. I'm finding myself not just asking what any given field in a form is for and making it justify it's self, I'm trying to figure out how to get by without it. I'm leaning towards going beyond just the bare minimum and into the realm of how can I modify this service to work with even less.