Last night was the launch party for the Palm Pre and I was lucky enough to receive an invite. Originally, I was a little perplexed; the invite touted:

• The launch of the Palm Pre
• An Interactive Farmer’s Market
• Support for the Veterans of Iraq and Afghanistan
• Jason Alexander as MC, Jerry Seinfeld as entertainment

This mish mash of options seemed a little confused, but the event panned out to be highly cohesive and very enjoyable.

Lisa, Greg and I (preDevCamp organisers) went together and had the opportunity to meet Pam Deziel (Palm) face to face for the first time. We also met some of the developers who’ve been working on the Pre these past months. We also ran across precentral.net‘s very own Dieter Bohn, who was one of the lucky few to get to review the Pre.

The Farmer’s Market turned out to be a very nice way to keep everyone fed as well as raising money for the IAVA. Each stall was giving away food as well as selling wares, with money going to support the veterans of the recent conflicts. You may have seen their advertisements (in the US); they do some great work and I would encourage you to find out more and make a donation.

The reason we were there, however, was the Pre. I finally got to get my hands on one. They had demo stands, with Palm reps showing them off. They were still a little guarded about giving them out, but I was allowed to hold one and have a go on the keyboard and with the touch screen. I think the keys will take a little getting used to, of me. I have big hands, so these micro keys are a little troublesome, but the Pre keys are bigger than my Blackberry’s (in terms of area) but flatter, so less tactilely pleasing; all in all, I’m happy with the keyboard. The phone itself is a great shape and weight. I love the rounded edges and, while they wouldn’t let me put it in my pocket, I think it will fit more comfortably than my past phones.

I didn’t get a chance to really play with the software as there were many clamouring hands. I did get the chance to load up the preDevCamp website, however and it looked HOT! It also loaded up pretty swiftly too, which I found quite impressive.

All in all, a great night; met the other preDevCamp organizers face to face, met some Palm muckamucks, played with the Pre, got free food. I classify this, a WIN.

The past week has seen a lot of change at preDevCamp. It’s been a busy time, but I believe we’ve found our footing again and it’s time to move forward.

Following our challenges with Palm, whurley and gio have opted to move on to other things. We wouldn’t be where we are without them and I’ve eternally grateful to them for all they did for preDevCamp. I hope I’ll see them at their local events and hope to work with them again on future projects.

Joining the organizing team are Lisa Brewster and Greg Stevenson. I’m very grateful to them, since preDevCamp is, in no way, a one person job.

We’ve spoken to Palm a number of times now and they’re very positive about preDevCamp. They’re offering support and we’re working with them to determine the best way for that support to manifest itself.

Finally, we settled on a date for preDevCamp which balances the various pressures of SDK availability, organization time and conference conflicts. We settled on August 8th and, so far, this seems to have gone across well.

Watch this space for more updates, as they come!

Back in February, Whurley, Gio and I heard about a new product called the Palm Pre.
I was excited at the promise of a new, open mobile development platform and we decided to recreate the success of iPhoneDevCamp by creating preDevCamp.

I never expected Palm to provide assistance, but I hoped they would. Apple was flooding the market with advertisements, not for the iPhone, but for the iPhone App Store and the abundant apps.
Clearly, a thriving supply of mobile applications was the way to sell a new mobile device.

I’d developed apps for Palm OS in the past and I knew that there was a devoted community of developers out there; however, they were rather neglected developers, since Palm hadn’t really been a major player in the mobile arena for a while. With the advent of the Pre, I thought things were changing.

Time went by and there were fleeting moments of contact with Palm. We spoke to them; they seemed interested but asked us to put a disclaimer that we were not affiliated with them, before they would enter into a relationship with them. This seemed a little backwards to me, but we complied. Not much transpired after that.

Then Mitch Allen gave his web presentation on developing WebOS apps and gave us a shout out. I was really excited about this; the CTO of Software was aware of what we were doing, but there wasn’t any follow up from Palm following that.

Finally, last week, Palm sent us some NDAs in preparation for a meeting this Wednesday. We signed them and prepared ourselves for an interesting update. Gio sent out a tweet simply stating that we had a meeting and it was under an NDA, as a result Palm then cancelled the meeting and cancelled any discussions covered by an NDA. At that point, my hopes for a useful relationship with Palm died.

As a corporation, I acknowledge that Palm’s only responsibility is to its shareholders. There’s nothing self serving or evil about that; it’s how things work in big business. However there are many keen and willing developers out there, who have been waiting for the arrival of WebOS. A development platform is only a success if it is broadly adopted. Instead of embracing the grassroots upswell of interest in WebOS that preDevCamp fostered, Palm seem to be, at best, oblivious and, at worst, disdainful of the enthusiasm and good will engendered by these folk. I think they are missing a real opportunity to be involved in and to help generate the growth of a vital community.

My fellow preDevCamp founders and I may have differing views on the impact of Palm’s interactions with us. Personally, I’m left disappointed at what I view as a lack of foresight on Palm’s behalf. Palm will live or die by the success of the WebOS platform. The preDevCamp community will be a large part of this. However, my excitement remains about the WebOS platform. I couldn’t really give two hoots about Palm at this point. I *do* want preDevCamp to be a success and I *know* it will be; we have dedicated organizers all the way across the globe. We have a release date, at last. We have a date for preDevCamp. It’s all systems go. I encourage you to stay focused on the product and on the exciting possibilities that WebOS brings. My only hope, now, is that Palm runs the course with their indifference to community. If they don’t want to help us, that’s fine. I just hope they don’t try and get in our way.

So, it’s been over a month since I last posted, but things have got busy. Here’s what I’ve been up to:

• preDevCamp has bloomed! We’re still waiting on Palm/Sprint to announce a launch date, but I did get my hands on a copy of the SDK and am looking forward to playing with it.
• I got involved in an organization called Linux Against Poverty. That’s all I’m saying for now, but watch this space for more details
• I launched nerdnite Austin with JC. I also revamped the nerdnite website which went live last weekend.
• I’m moving house. Closing this Monday. Yikes!

Consider this my return post. I’ll be posting more often once things have been sorted with the house… see you soon!

Update
(Thanks to my sister for the prodding!)

I have spent a fair amount of time setting up the hosting for my sister’s site: http://purplestarconsulting.com. If you’re an Atlanta based small business and need assistance with marketing and web presence, go check her out!

The other day, the preDevCamp team published our ‘PreView’ map at http://predevcamp.org/preView.html. In this post, I’ll talk about how it was put together.

PreView is a combination of the Google Maps API and the Twitter API. Without wanting to shatter the mystique, I’m going to outline how I set about creating PreView.

First, take a look at the HTML in preView.html. When you strip out the preDevCamp menu and Twitter Bird, you’re left with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<html>
<head>
<title>preView - Global Twitter interest in preDevCamp, Palm Pre and webOS</title>
<link rel="stylesheet" type="text/css" href="/css/preView.css" >
<script src="http://maps.google.com/maps?file=api&amp;v=2.x&amp;key=xxxxxxxx" type="text/javascript"></script>
<script src="http://gmaps-utility-library.googlecode.com/svn/trunk/markermanager/release/src/markermanager_packed.js" type="text/javascript"></script>
<script type="text/javascript" src="/js/jQuery.js"></script>
<script src="/js/tweetList.js" type="text/javascript"></script>
<script type="text/javascript" src="/js/preView.js"></script>
</head>
<body>
<div id="tweetAPI">Checking Twitter API</div>
<div id="preViewMap">Loading Google Map</div>
</body>
</html>

As you can see, the BODY of the page is exceptionally simple; just two DIVs with ids set and some basic content. All the hard work is done by the Javascript in the HEAD of the page. So how does it all work? The ‘preView.js’ script creates an object called PreView which pulls together jQuery, Google Maps and Twitter.

jQuery

jQuery is a library that extends the Javascript language and makes it easier to perform Web 2.0 functionality in a way that works independent of your users’ browsers. You can find good tutorials on jQuery all over the Internet and the docs are pretty good too, with lots of examples. One thing that I discovered the hard way is that your CSS links must appear before loading jQuery or else you can find you have problems when you try to access CSS properties in later code. For the life of me, I can’t figure out why this is so, but that’s how it works.

Other people might say Prototype or YUI. I haven’t used either of those, so I can’t comment, but I will be learning Prototype soon, since it underpins a lot of the webOS language.

Google Maps

The next step is to create your map. I used the Google Maps API for this. To access the API, you need to get a key from Google. This allows them to track how people are using their API and who is making requests. Your API key is associated with a specific domain, so for preDevCamp, we need 3 keys; one for ‘.com’, one for ‘.org’ and one for ‘.net’.

In addition to pulling in the Google Maps API, we used the Marker Manager for handling all of those little Palm Pres dotted over the map. The Marker Manager improves performance of map panning by only drawing the Pres that are currently visible. As preDevCamp grows, we’re going to have more and more Pres on the map, so this will get more an more important.

Once the API is loaded, you have access to all of the Google Maps commands. The API documentation is the best place to go to understand what each object does, but here’s a breakdown of what PreView does:

1. Locate the destination DIV for the Google Map
2. Create the GMap2 object and associate it with this DIV
3. Add a small Zoom control
4. Centre the map on 50n,0E. This is in the English channel, directly south of London. There’s no great geographical significance of this point, but it makes for a map that feels reasonably centered, with regard to land masses.
5. Set the map to a Physical map instead of a Satellite Image map
6. Create a new Marker Manager and associate it with the map
7. Make a JSONP call to the preDevCamp website requesting the location of all the preDevCamps. This returns an array of JS objects, each containing the Name, Longitude and Latitude of each preDevCamp city (see geocoding below)

That’s it for creating the map!

Geocoding

Geocoding is the transformation of an address of some sort into a latitude and longitude. Google Maps provides a geocoding interface and you can translate addresses on the fly if you need to. However, the geocoding service is rate limited and if you request too many, too quickly, your requests will get rejected. In addition to this, it takes a certain amount of time to send the request and get a response. As a result, the geocoding results have been cached on the preDevCamp server and are taken from there. This also allows us to handle ambiguous locations, such as “Washington” or “Charleston”, which could refer to a number of locations. Since we know which city each preDevCamp is in, we can add special handling for cities such as these.

That said, the geocoding service is used to find the Latitude and Longitude of Twitter users, based on their reported location.

Twitter API

Once the map is created, all that remains is to query Twitter for relevant Tweets. Like the Google Maps API, the Twitter API is really well documented. They actually have 2 APIs. One is for searching the Twitter public time line, the other is for interacting more explicitly with Twitter. One thing to note is that the Twitter API is also rate limited. You’re restricted to 100 API requests per hour, unless you get a special dispensation from Twitter.

So, the first step PreView takes is to find out how many API requests are available. It also checks to see when this limit will be reset and will use that later on, if the limit is exceeded

PreView continues by sending out searches for ‘predevcamp’, ‘webos’ and ‘palm pre’. Each of these requests generates a list of Tweet objects which are put onto a central list which sorts by each Tweet’s ID. The ID is globally unique. At this point, PreView does not filter duplicated Tweets, but a future version will.

The next step is to go through the list one at a time and display the Tweet on the map. In order to do this, we take the location property of the Tweet and send it to the Google Geocoding Service. Although this Service is rate limited, we only show Tweets once every 8 seconds or so, so we’re not going to hit the rate limit that Google sets. However, asking Twitter where a user is located, does count against our Twitter API usage, so we make sure to cache users’ locations to prevent the limit from being gobbled up.

If the user’s location does not translate, we put the Tweet somewhere in the middle of the Pacific Ocean. There may be a better way to indicate that Tweet cannot be located but, again, that is deferred to version 2.0.

Once all of the Tweets in the list have been shown, we send a second request to the Twitter Search API. Twitter has a neat trick to help us here. When we send a search request , Twitter gives us a list of Tweets as well as a URL that we can use later which essentially says: “Show us the Search Results starting from where we left off in the last search”. This means we don’t need to filter for Tweets that we’ve already seen.

Summary

Hopefully, that’s given you an overview of what I sought to achieve with the preView map. By looking through the source code and reading this post, you should be able to see what it takes to make something like this. The astute of you will also see areas where preView could be improved and, when I have time, I’ll be taking a second run at it. However, for now, I hope that it proves to be an instructive read!

If you don’t know, webOS is the new operating system that Palm have created. Instead of having to write apps in Objective C or Java, Palm have opted for having HTML, Javascript and CSS as the language of choice. I think this might be a smart move on their part; the number of applications that developers write is directly proportional to the number of developers who actually have the expertise to code for this platform. However, I think Palm have only made half of this smart move.

If you want to change the game, you sometimes need to bring in new players. Right now, the smartphone application development arena is populated by Objectve C developers and Java developers. Many of these developers have been mobile application developers for a long time. They bring great experience with them, but they also bring history. They look at applications in a ‘mobile’ way; this is not necessarily the best way. Palm seem to have opened the door, but they’re not doing anything to point the door out to people or to encourage them to walk through it.

I want to see web developers sit up and take notice of webOS and the Palm Pre. For one thing, it’s an opportunity for them to branch out and extend their repetoire. They don’t need to learn a new language; just an alteration in architecture and a new framework. With very little effort, a seasoned web developer can become a webOS developer.
Also, web developers are used to the stateless nature of web pages and have learned to work around this with cookies and HTML 5 Storage functions. In addition, they’re used to JSON and working with DOM manipulation. That means that they can concentrate on the important aspect of generating innovative ideas for apps, instead of getting to grips with a new language.

Bringing in developers without a traditional mobile mindset will, no doubt, result in some applications that really don’t perform well on a mobile platform. However, it also brings the potential for some really great ideas, unfettered by the idea of ‘what is possible’. Again, Palm do not appear to be highlighting this; instead they are highlighting the number of PalmOS developers that they have.

The thing is, the number of web developers in the world is staggering. Palm claim 30,000 developers in the Palm development community; contrast this with the over 4.5m downloads of the development version of  jQuery last year alone… that gives you some kind of indication of how many web developers are out there.

If you’re a web developer out there, looking for a new challenge, take a long hard look at the Palm Pre. If you’re interested, go over to the preDevCamp website and sign up or organizer a local event; join an evergrowing group of developers excited by this new platform. As a founder of preDevCamp, I have to admit a bias, but I’m not waiting for Palm to realise what they’ve got here

O’reilly release the first chapter of their new webOS book in the past few days and it has been a welcome island in a sea of tedious rumours. While others may wildly speculate on when the Pre will appear, at least we now have some idea of what it will be running.

So what does this chapter tell us about webOS? Well, a lot of the chapter is spent with the usual overview. I tend to skip these chapters in technical books, but webOS is brand new to me, so I gave it the time. Here’s what I learned:

• webOS is expressly intended to support multiple hardware environments with all sorts over screen sizes, resolutions and orientations – This tells me that a good webOS App will not restrict itself to functioning on a Pre form factor
• webOS will use HTML 5 tags to provide storage functions and some graphic functions (using the canvas) – This tells me that I need to get up to speed on HTML 5 and start playing with it in Firefox
• webOS will give you access to Calendar and Contact data, Location Services, Accelerometer data and XMPP messaging  – This tells me that the apps we can make are going to be awwwwesome!
• Mojo will come bundled with the Prototype framework – Since I’m a jQuery fan, this means that I have to learn another JS framework, if I’m going to be able to fully exploit the Pre
• The Core OS will support fat32 for media file partitions (with a mention of mounting via USB) – This suggests that it may be possible to plug a USB drive into the Pre for extra storage and ease of file transfer!

There are some  nice pieces about design philosophy and UI considerations in the first chapter and some high level introduction to concepts such as stages and scenes.

All in all, and interesting read; certainly enough to whet my appetite for the Pre. Here’s what I’m going to be doing in preparation:

1. Learn HTML 5
2. Learn Prototype

I think focusing on those two, for now, will put me in good stead. I recommend the same to you.

I saw @mhat‘s tweet today about ‘What language should I learn‘  and it got me thinking about the times I’ve asked that question and how I might answer it. So, @mhat, I’m taking your tweet to be a challenge to write an unbiased and ‘unwrong’ post. To do this, I’m going to give you a history of the languages I have learned.

The early years

As I wrote in my first post, I started at a tender age, on a ZX Spectrum. The Spectrum came with a dialect of BASIC, called ‘Sinclair Basic’. Like all BASIC derivatives, it’s a high level language, however unlike modern flavours of BASIC, it was untyped and unstructured. Lines of code were entered with the line number provided explicitly. There was no variable scoping and subroutines were implemented as a special ‘GOTO’ called ‘GOSUB’ which allowed you to ‘RETURN’ to the next line. However, since there was no variable scoping, recursion was impossible.

That said, I was 5 at the time, I wasn’t too worried about recursion at the time. My programming was limited to copying code out of books containing page after page of ZX Spectrum programs. My brother and I would diligently type these out, then play the game for a while and then start playing with the code to see what changes we could make. This process was about as successful as genetic mutation. More often than not, our change would kill the program, but sometimes it would lead to great stuff.

As we got older, our 48K Spectrum was replaced with a 128K Spectrum. Along with the extra memory, came an update to BASIC to include keywords that allowed direct access to the MIDI chip. I continued to mess around with BASIC, making programs that would play both hands of a piano score, as well as simple games.

The IBM PC arrives

My first experience with an IBM PC was the 286. I migrated from Sinclair BASIC to GW-BASIC. At this point, I was writing programs from scratch, including a text adventure called ‘Loup-Garou Chateau’. Tragically, this game has been lost from prosperity, but it was my first foray into actually designing a program before coding it. I chose GW-BASIC, simply because I was very familiar with BASIC and it made for the simplest transition.

As the years passed, I would inherit my dad’s old computers, moving up through the 386 to the 486. At this point, I got my hands on Visual Basic. Again, this transition was driven by the ease of transition from what I knew to something new. This was my first experience with a proper development IDE, as well as my first experience with creating GUIs. Beyond that, it wasn’t a great step forward to me… that would come during university.

Coding gets hardcore

I never studied computing at university; I was a physics student. However, the course I took, included some small computing components. For one lab rotation, we learned how to use computers for physical analysis. This was back in 2000 and they had us coding with Pascal. At the same time, I was playing with C at the suggestion of my dad. For the first time, I was learning about functions and variable typing. In addition, I was programming with the intention to solve problems that were being presented to me, instead of just ‘playing’ with a language and seeing what it could do. When you have an externally provided problem to solve, you’re forced to learn how to use new facets of the language. If you’re just playing around, you can be limited to seeing what you can do with the parts of the language you understand.

While at university, I also participated in an Electronics lab which involved learning about the 8086 processor. We had an experimental board which allowed us to commit opcodes to a region of memory and then execute them. As part of the practical, we actually had to wire up the SUB instruction, by running the clock signal through the appropriate logic gates and to the appropriate ALU pins. This was my first experience with the lowest level of programming.

In the summer between my second and third years, I spent four weeks working for Milford Instruments. While there, I developed a DMX-512 Transceiver Controller. I was working with the SX-Chip from Parallax and learned how to write assembler, how to work with interrupt handlers and how to get microcontrollers to talk to other microchips. For 4 weeks, I worked on the firmware and the hardware and really learned what programming was all about…

Coding starts to bring in money

My month at Milford Instruments made me realise what I wanted to do with my time; I wanted to get into development professionally. It was an obvious choice to apply to IBM and I started working at their Hursley Development Lab, one weeks after school ended. They had me working on a protocol converter, (this time, a SCSI-SSA converter) and, as before, it was coded in assembler.

After a couple of years working on this, I moved to work on one of their Storage RAID controllers. This time I was coding in C, the first time I had done so, professionally. However, alongside all this production code, I was steadily learning how to write Perl and Korn Shell scripts for developing test rigs. I was also teaching myself how to code for the web. I’d done some basic page development while at university, but I was beginning to learn about dynamic pages and DOM manipulation.

My next move got me into support and I started writing a web-based support tool. It uses Perl and MySQL in the back-end and HTML and Javascript in the front-end.

The main thing I got from the IBM Development Lab was the chance to be surrounded by people writing a wide variety of code to solve a wide variety of problems and be exposed to what other people were doing with languages that I both knew and that I had never heard of. I learned that there is really no such thing as the one perfect language, rather the best language for the job in hand.

What’s the point of all this?

So, what’s the point of this post? Is it possible to write a post about “Which language should I use” that is not biased and has some value? I hope so. Here’s what I feel I’ve learned over the years.

People write code for a wide variety of reasons. The language that they code in is also determined by a multitude of factors. More often than not, we don’t have a truly free hand when it comes to choosing the language we’re coding in. However, looking back, I believe I see some benefits in the track I took.

• Learning C allows you to truly understand what higher level languages such as Perl or Java are doing with objects and references. Although people get scared off by pointers, if you don’t understand the concept, then you’re going to struggle with the idea of references. Since all languages have variables, if you can get those nailed and totally understood, you’re going to be in good stead when you move to a language which brings new data types
• Learning Assembler allows you to truly understand what C is doing with pointers. Assembler has a tiny command set and you have to tell it to do every last thing. It’s a struggle, but once you’ve got assembler in your tool belt you’re in good shape. You may never go back to it, but the lessons you learn from it can be applied all the way up the language stack
• Learning a wide variety of languages allows you to truly understand the patterns of development that are language-independent and stops you falling into the trap of becoming a language bigot. There’s nothing wrong with having a favourite language, but saying that one language is categorically better than another because of the presence of a specific feature is like praising Inuit for its wide variety of words for snow. That’s fine if you’re describing snow, but not much use if you want to discuss the surfing conditions in Hawaii.
• Learning a language is a lot easier if you’re trying to solve a specific problem that has come from an external source. This is why it’s such a good idea to do the exercises if you’re learning from a textbook. There’s nothing wrong with playing with a feature for its own sake, but unless you have some factor that is external to the language driving you, it’s going to be tough to learn all that the language can do.

Did I just cop out?

So, did I just cop out of the question? If someone asked me what language they should learn, how would I answer? That depends on the person. If they were just starting out, I would say Perl or Python. These languages have a huge development community and millions of pages dedicated to coding in them. They are in common usage and show no signs of disappearing in the near future. They are neither arcane nor limited in their range and they allow for procedural and object oriented style programming, meaning that the developer can transition to OO without having to change languages.

If I was being asked by someone with a reasonable amount of development, I would strongly suggest Javascript. As the powerhouse behind Web 2.0 and the basis for coding on the Palm Pre, it’s critical to know this language. However, testing and debugging Javascript is not a trivial task and requires a developer who is comfortable writing code that has ‘a good chance’ of working so that troubleshooting is limited to ironing out wrinkle. Also, the problems of cross-browser support are bewildering enough for experienced coders; exposing a brand new coder to Javascript would probably be the end of their efforts in the field.

If someone wanted to spread their wings a little, I’d strongly suggest taking a look at Assembler or some other microprocessor based language. It’s still coding, but you’re forced to truly understand your code’s interaction with external factors that don’t care about your nice neat program. Spending time debugging microprocessor code; especially code that interacts with an external piece of hardware, gives you a true understanding of the many ways that code can fail to work.

On a number of occasions this weekend, while I was at the BLI Conference, I was asked the question: “Why are you doing the preDevCamp?” I thought it would be useful to provide an answer here.

With the ever increasing complexity of mobile telephones, we’re now carrying powerful computers around with us every. Unlike modern computers, the mobile phone has remained an arcane platform for programming. iPhone development requires a knowledge of Objective C. If you want to write for the Android, you’re stuck with Java. While these languages are hardly esoteric, they’re hardly an easy environment to use for creating simple applications.

I’m a firm believer that the greatest barrier to innovation should be imagination and not technology. The opening of the iPhone App Store presented the fruits of many a fertile mind; minds that had a good idea and coupled that with a sufficient understanding of Java to turn that idea into an app.

With the release of the Palm Pre, will come a new environment for developers. This environment is the webOS and applications will be based on HTML, CSS and Javascript. The number of developers who are comfortable with this development environment is vast, much greater than the number of Objective C developers. In addition to this, HTML and CSS are inherently visual languages, making te development of graphical interfaces well within the reach of the average coder.

I’m excited at the prospect of preDevCamps, because it’ll be an opportunity to see what developers can do when they are given the chance to spend their mental efforts on innovating instead of creating; the DevCamps will be run all around the world, bringing ideas together from cities ranging from Atlanta to Zagreb. Together, we’ll be able to demonstrate that the Palm Pre is a serious platform for developers and has a real place in market. Already, ideas are flowing on the discussion forums and we’ve only been going a week.

I urge anyone who is event the slightest bit interested in web development to take a serious look at the Palm Pre and joining a local preDevCamp. It’s a real opportunity to take the skills that you honed on the web and learn a brand new way to exercise them!

I spent the past 2 days at the BIL Conference in Long Beach, this weekend. I was, once again, reminded of the value of conferences in the technology arena.

All too easily, people look at technology as an impersonal enterprise, focussing on software and hardware and overlooking the human element. However, attending a conference reminds you of the power of meeting people face to face and talking to them about their ideas. I actually spent very little time sitting in presentation, but I spent a lot of time meeting new people and talking about what they are doing and what I am doing.

  To travel and be away from home, it’s important to feel that the time was well spent. In order for that to happen, you need to take responsibility for how you’re spending your time. I was lucky to be travelling with whurley and so met a lot of people through him. I was also lucky enough to meet a number of preDevCamp organizers and volunteers and was re-assured that preDevCamp is going to be a great success!