Over the past week I was invited to join the team here at Gaia Resources for some work experience and to see how a different company runs compared to my past experiences.

A bit about me…

My name is Jayden Lambert, I am 16 and have recently completed my Certificate IV in Networking, I currently work part time at Kolbe Catholic College in Rockingham within the IT deptartment. As I am still only 16 I am still considering my options, I took the opportunity to come to Gaia Resources to see the differences in which a company such as Gaia compares in comparison to my present position. Coming from a school background to an office was a pleasant surprise! I found that I could actually hear myself think and was able to concentrate!

During my week here I have participated in a number of different tasks some more challenging than others, I touched up on my cable management and soon learnt that it is easy to forget where you unplugged a cable a couple of seconds before! Whilst at TAFE you learn things such as mapping a network I put my skills to the test and created a simple map of the network here in the Gaia Resources office.

Developing the network diagram

Along with the network diagram I also created a map using QGIS (http://www.qgis.org/) to make a view of the office including all of the network points and their numbers, this allows the technician to look at the sheet in order to find where a port is located instead of walking around to each individual room.

The network map

Mapping is one thing, being able to physically change it is another, with the help of Anthony we installed a network cable in order to allow the printer to be shifted, this took some troubleshooting.. have you tried to shift a printer? Whilst completing this task I also gained a bit more knowledge and practice in patching, making and terminating network cables.

Over the past week I have thoroughly enjoyed my time at Gaia and would like to thank the whole team for their hospitality and taking time to show me a range of different skills and processes different from what I am used to.

Jayden Lambert

A very big thankyou for all your help over the week you were with us Jayden! Gaia Resources has benefited greatly from your enthusiasm and efficiency in dealing with the tasks we’ve given you, and I hope you enjoyed your time here!

Feel free to leave us a message below in the comments!

The post Work Experience appeared first on Gaia Resources.

Those with a desire for more technical details, read on!

The system

Below is a diagram of the systems architecture that we eventually settled on for the experiment (click to embiggen).

As you can see, quite a complex systems architecture, but by no means unachievable particularly given that the majority of components were simply off the shelf. One of the beauties of using the Arduino platform is that it is well documented, well supported and there are quite a range of shields and compatible sensors around, so interfacing them requires only a basic electronics knowledge and often little to no soldering. So, starting at the left, I’ll walk through each of the major components of the experiment.

Firstly, the temperature sensors were to be mounted into test vessels furnished with either black or white tin roofs and varying thicknesses of reflective clad insulative rubber. The picture below shows the construction of the test roofing materials:

The sensors themselves are a relatively cheap off the shelf product that ScienceMob and JCU have developed a calibration technique for, which gives them a 0.1 degree C accuracy. This is a great example of being smart about technology which results in very high quality data capture at a cost-efficient price. The sensors were simply mounted into a flower pot on which the roofs were to be mounted. You can find more information on the temperature sensors we were using here.

These pots were then buried out in the yard of the Sustainability Centre in the sun to see how they would react to the sun’s warmth. The temperature sensors are a Dallas 1-Wire device which means that you can connect multiple sensors up to a single input on the Arduino. To do this, however, you either need to connect multiple devices up, to a single wire, and the way that we did this was via a custom board that Scott put together to act as a 1-Wire hub:

We did find that there are many limitations with the use of 3.5mm audio jacks, however, and in the future we’ll be using something a little more robust and weather resistant.

Incidentally, by the time we’d gotten to this part of the build, the room we were using as a workshop looked something like this:

From here, the next pieces of magic are mostly in code. The Arduino microcontrollers are programmed in a C like language into programs called sketches. On the sensor Arduino (the Stalker) Jerry from JCU wrote a sketch that woke up the board periodically based upon an interrupt from the Real Time Clock on the board. This meant that the power consumption of the board could be kept to an absolute minimum, which was requirement considering we were powering the unit from a solar panel and a small lithium rechargeable battery. Once woken, the board would then poll the temperature, humidity and light readings from each of the sensors, run this through the calibration algorithms for each sensor to correct the quality of the reading, and then write this out the XBee Wireless module.

The other Arduino in the setup was a Freetronics EtherTen. This board was configured also with a Xbee module and sat there listening for sensor updates from the Stalker. When updates were received, the EtherTen was programmed to convert the sensor readings into an HTTP request that was sent via ethernet to the 3G modem and over to a Gaia Resources server in our datacenter in Perth. The server was setup with some simple PHP scripts to write the sensor readings into a PostgreSQL database for later analysis and visualisation. We also put together some simple webservices to provide querying into this dataset and pulling the data out in JSON format.

Finally, we knocked together a simple HTML page that used the webservices that we wrote earlier, the Google Maps API and the Google JSAPI to show some near real time graphs of the data feed (click for feed):

All up, not a bad effort for a day’s work.

So what did we learn?

Tech Sprints are an excellent way to rapidly prototype a solution for a problem. The best thing about these kinds of events, however, is not that you get the job done, it’s that you get a really good understanding of the problem – the gotchas – that enables you to put together a really robust and tuned solution in a more realistic timeframe. Some of the gotchas we encountered were:

• Weatherproofing – This kind of experiment if very subject to weather conditions and the elements. This became very evident the morning after the sprint when we discovered that the massive downpour that had occurred overnight had swamped the 1-Wire hub with water. Always ensure you have enough weatherproofing for the environment in which you’re deploying into.
• Fabrication takes time – Especially when we’re mostly electronics and computer geeks. Regardless, I think we did fairly well in this regard and were able to get a good test bed up and running in the allocated time.
• Teamwork and Leadership – I think we did this quite well. Scotty had a great understanding of the system as a whole, and ensured that we had expertise in all areas of the system present so that when the time came to integrate various parts of the system, we always had someone on hand who knew how to do it. The willingness of everyone present to simply jump in and do what was required is what made this Tech Sprint work.
• Define your interfaces between components and build test data to support development of them – We did this both well and poorly depending on the part of the system. Many of our interfaces were standards based. The temperature sensors utilised the 1-wire standard, so Scott could go off and build the sensors whilst Jerry programmed the Arduino to talk to them. The flower pots were all a standard size so Ian could go off and dig standard size holes… What we didn’t get so right was the test data. We did find on a couple of occasions that we were waiting on one part of the system to be complete before we could finish testing and developing other parts – for example, waiting for temperature data to be published to Xbee so that we could feed it up to the Web Services.
• Always bring spare parts – For when there’s a downpour and your equipment gets drenched. It would also have been handy if we had another Xbee module so we could snoop on the over the air data without having to pull apart our experiment rig.
• Be flexible – We were really good at this. When something isn’t going to work, move on and try something else. This occurred several times throughout the day and without this flexibility, I don’t think we would have a working system now.

The future…

The future of this experiment hasn’t been written yet, but I’m sure most of you reading this can see a bunch of ways this technology could be used. Although temperature sensing is interesting and useful, it’s really just the tip of the iceberg as to how this could be applied. We spent some time workshopping sensors, platforms and applications for this system and the results were wide and varied. Some examples are:

• Acoustic sensing & automatic categorisation of birds, bats, frogs
• Moisture, flow rate, humidity sensing in various levels of rainforest strata
• Ocean current and water chemistry sensing
• Motion activated camera traps with correlated environmental data
• Cloud cover and cloud height
• Video and photo monitoring
• In vehicle/aircraft monitoring (think black box recorder)

All of which could be remote, self powered and low maintenance and feeding back in real time, or it could be off the grid and recording to local storage.

The aim of this experiment was to prove that this was all doable, and I think we’ve got a compelling enough evidence at this point to prove that it is!

Contact me via twitter, email or leave a comment below.

The post Sprinting to a Low Cost Sensing Platform appeared first on Gaia Resources.

As this is a fairly long article, i’ll summarise by stating that for about 100 bucks, you can put together one half of a 5km wireless network link in an urban environment that in my case achieved 54Mbit at 15% packet loss and 12ms latency. Read on for the details…

I’m sure most people reading this article have at one stage or another connected to a wireless network of some kind. I’m also sure that most people have at one stage or another been frustrated by wireless dropouts. There have been a few wireless networks that I’ve worked with that have been absolutely rock solid, however, this I’ve found to be the exception, rather than the norm. Yet, despite these fairly common issues with WiFi, the wireless market is now flourishing with almost every modern phone, tablet, computer and now even home appliances such as TVs boasting wireless connectivity options. So why is this the case?

Up until recently, many people been wary of wireless networks due to their dubious reliability and limited range. Sure, every now and then you read an article online about someone who’s achieved a billion mile range using a home made cantenna or modified Galaxy dish, but when you read into the detail, it’s always within a carefully controlled environment with perfect line of sight, tall masts and high powered transmitters. Well the reason these people manage to achieve these kinds of results is exactly that. Wireless networks are all about the right equipment and network topology for the situation. In the past I have been involved with a variety of interesting wireless deployments such as 802.11a/b/n networks deployed into the bush to provide communications between sites, vehicles and mobile devices. In the industry I was working in at the time, however, we were lucky enough to have the resources to purchase specialist equipment that made the job of putting together a robust network fairly straightforward; in a domestic or small business environment, this kind of equipment has been cost prohibitive and complicated to setup.

Over the years experimenting with wireless I have had great hopes and much disappointment when the equipment doesn’t do what’s promised on the box. This week I started experimenting with long range wireless communications. I’ve been planning on trying out some long range experimentation for many years now, but it was really my rediscovery of the WAFreeNet project that again peaked my interest. The last time I looked at this project would have been late last century when I was living in an apartment and had no chance of mounting any sort of antenna or mast on our premises, but in the years since, I’m now in a position that I have control of my own roof (even if it is still owned by the bank). WAFreeNet is a network of networks based mostly in the Perth metropolitan area, however it does have links via virtual private network (VPN) to Kalgoorlie and even Adelaide. It is kind of like the internet in the early days, however it’s mostly based on wireless networking, rather than hard lines. You can see what their network topology looks like here.

So, the challenge for me was to see what it would take to link into WAFreeNet, and it turns out, it’s easier than I thought.

The first step I took was to have a look at the network topology for the WAFreeNet to get an idea of the bearings I would need to line up for a point to point connection to my nearest WAFreeNet nodes. There are several nodes around my house, but due to the landscape, many are not within line of sight. I used a few tools recommended on the WAFreeNet site here to help me out:

In the line of sight (LoS) graph above, my house is the central point and I have graphed the line of sight to two nearby WAFreeNet Access points. You can see here that i have a nearly perfect shot to the access point on the left, and if I can put my antenna high enough, I will have a clear shot to the one on the right also. (Although the one on the right is a 5.8GHz access point, and i’ve only been using 2.4GHz gear in my testing).

The next step involved doing an RF survey from the roof of my house. To do this, I used a USB directional wireless adapter that I’ve used in previous experiments and some handy software called NetStumbler which allows you to scan for wireless signals and record the signal strengths, channels and access point names. Interestingly, I was quite surprised to find a whopping 65 wireless access points visible from my roof. I was also quite pleased to see that all but two of these access points had at least basic security enabled on them (although it is quite easy to crack both WEP and WPA1 networks). The most valuable find of this part of the survey was, however, that I had managed to locate one of the WAFreeNet nodes. It turns out that the node that i’d seen from my rooftop was in fact a little 5km line of sight from my house (in fact, it was the node on the left of the LoS graph above which has the scale in miles).

Finally, I was armed with enough information to try to setup a prototype for trying out a real world long range wireless shot. The hardware that I chose to use is some pretty cheap off the shelf hardware. In total, at today’s market prices, you’d expect to pay around 100 dollars for the wireless router, antenna and cabling. The most important attributes when selecting hardware for this kind of network link are:

• High power output – Generally, the more power you can push out from your transmitter, the further you can send your signal.
• Antenna gain – Generally, the higher antenna gain, the further you can transmit and receive, although antenna gain and design will also have a significant affect on the direction and shape of the transmission ellipsoid.
• Antenna directionality – A high gain antenna is one thing, but being able to focus it in a particular direction has its own advantages and disadvantages. Think of it like a magnifying glass that’s used to focus the sun’s rays in a particular direction.
• Antenna mast – Almost always, the higher the antenna can be mounted, the better chance is has to clear obstructions.

Of course, all these aspects need to take into account federal regulations for wireless communication, local council regulations for antenna masts, and must be legal. In the end, I went with a really cheap TP-Link Wireless Router, an SMA extension cable, a TP-Link Flat Plane Direction Antenna, and a short length of wooden dowel for my mast.

Step one was to setup the wireless router on my LAN and configure client access point mode. I figured that it would be easiest to align the antenna if I was to take a laptop up onto the roof with me so that I could log into the wireless access point and observe the signal strength whilst making adjustments, rather than running back and forth.

Once all the configuration parameters where setup, the next step was to get up onto the roof, route the coaxial cable for the antenna and mount the antenna on the roof. Because I was doing this quick and dirty, a short length of dowel was to provide my mast, simply bolted to a section of pergola. Hopefully this would provide enough height to get over the neighbours house.

The procedure for aligning the antenna was pretty straightforward, simply a case of turning the antenna on the mast, and observing the difference in signal strength on the web console. Once I’d aligned the best signal I could, it was back down to ground level to do some testing during which I found that whilst I had a good strength connection, it was a little intermittent, with around 15% packet loss. What was very surprising however, was the low latency of the connection. Over the 5km wireless link, I was achieving a network latency average of around 12ms. That compares to an internet latency from home to work (we are on the same ISP, so it’s not going across the world to get to work) of 22ms. True, the packet loss statistic is less than desireable, however, in practical use, the link seemed quite reasonable for browsing WAFreeNet services and sites, and I’m pretty sure there is a correlation between the dodginess of my roof mounting and the packet loss statistic. I suspect if I was to reimplement the antenna mast, perhaps by piggy backing it onto my TV antenna mast (which is allowed to be 4 metres high in my suburb) I would be able to achieve a much more robust connection.

So what can I conclude from this experiment in wireless geekery?

• Firstly, it is very possible to achieve a long range wireless connection, even in an urban environment.
• Secondly, long range wireless can be done very cheaply.
• Thirdly, commercial off the shelf hardware has gotten to the stage where it is easy enough to setup complex networking arrangements quickly and independently. This technology has enormous potential for deployment in the field for communications between base station, field survey sites, vehicles and personnel. (Tracking, data collection, monitoring, safety…)
• Finally (and I haven’t really hinted at it in this article yet), ISPs and government regulation could have some major challenges ahead of them in the face of emerging networking technologies.

So, what are your thoughts on how long range wireless technology applies to you? Let me know in the comments below!

Contact me via twitter, email or leave a comment below.

The post Experiments with Long Range Wireless Networking appeared first on Gaia Resources.

There seems to be an expectation these days that the in built-in GPS in mobile phones and tablet PCs are not accurate and aren’t good enough for any serious location work. To be honest, some of our early testing was supporting this theory – however as we have been using the devices more and learning how to interface with them some interesting results are starting to emerge.

On our trip I took along a commercial grade dedicated GPS (Garmin GPSMap 60csx) with the aim of comparing the tracks between it and my trusty Samsung Galaxy Tab running the BDRS mobile tool. As you may have read from a previous blog article, we logged some 306 records over the two day road trip and this provided an ideal dataset to compare with the track produced by the Garmin. The idea was simple, log tracks with both units and compare the difference. You might recognise this photo from the earler article. What you might not have noticed is the second GPS sitting on the dashboard there…

The results were astounding! Not only was the tablet PC’s GPS in the ballpark of the dedicated GPS, the point data was mostly bang on. This was backed up by the spatial analysis done by Akeal of the Gaia Spatial team. Akeal was able to knock up an ESRI ArcGIS Python plugin in no time to perform a spatial analysis of the data by calculating the distance between the points coming out of the BDRS mobile tool and the Garmin GPX track log.

As you can see from the plotted points above, most of the GPS points logged from the tablet (dots) are right on the track produced by the dedicated GPS (yellow line). In fact, the detailed analysis shows that the median difference between the two devices was a mere 1.8 metres – well within normal GPS drift zones.

Whilst the mean difference is somewhat higher (around 4 metres), this can be explained by outlying points where the tablet has lost GPS reception due to standby mode, or where we haven’t logged data using the Garmin.

All up, I was very impressed at the quality of the GPS feed coming out of the Samsung Tablet and feel that it is more than accurate enough for most citizen science applications. We will be no doubt testing other devices in the near future, so stay tuned for more updates on the topic, but in the meantime, if anyone tells you you can’t get accurate GPS data from smartphones and tablets, they’re simply wrong!

AJ

Contact me via twitter, email or leave a comment below.

The post You CAN Get Accurate GPS from your Tablet appeared first on Gaia Resources.

Earlier this month, Benny and I attended a field exercise down in Brookfield Conservation Park, just outside of Adelaide. The aim of the exercise was to put into practice some of the methods being developed by TERN AusPlots for performing ecological surveys of rangelands, and to finesse the field data collection tools that we’re building as part of the Atlas of Living Australia’s citizen science project to support these methodologies.

After several false starts due to #Ashpocalypse2011, we armed ourselves with a surge protector (for the generator), a wifi access point and a bunch of laptops and android tablets, and jumped into a little rental Yaris (carbon offset of course) at Adelaide airport to head bush.

During the first day, we spent most of our time observing and later participating in point stepping, a process which involves surveying the surface substrate and vegetation at approximately 1000 points within a 100 by 100 metre plot. Each point in the plot requires at least 1 record, and when there are several species of vegetation the process may require four or five records to be made per point. You don’t need to be a mathematician to realize that there’s a lot of data to be recorded here and we came to the realisation that our tools, which were originally designed for the citizen science use case weren’t designed with such high volume traffic to go through them. We made several other discoveries about our tool during this session, and we noted down in as much detail as we could what we needed to fix or change.

Loading a new build of the mobile tool on a Samsung Galaxy Tab.

Our next step was a whiteboard session to figure out how we could support the kind of rapid data entry that we were seeing in the point intersect survey. After fleshing out a rough design and running this by some of the AusPlots folk, Benny set to work on the new data entry screen. Integral to the design were a number of adaptive quick link keys that add records based upon the species most seen during the survey and as much prepopulation of data as possible. With the new design we anticipated being able to reduce the number of clicks per point from around a dozen to just three or four.

The next day, I was able to take an early version of the new data entry screen out onto one of the test plots and start to give it a go. The difference was pretty remarkable, and I was almost able to keep up with the rate of data collection. A few more tweaks, and we were really getting somewhere. The rest of that afternoon was dedicated to getting these tweaks in.

On the final day of testing, we put the tool into the hands of the people who will actually be using it. At first it took a little while to get used to the software, but after only a few points along a transect, the data entry started to become smooth and rapid. Interestingly, there was no clear winner between the tablet and the mobile phone in terms of end-user preference. Some people preferred the phone, others the tablet.

Data collected along a transect, as these are clustered points, there’s actually a lot more than appears (see below).

Zoomed in points along a transect, note the GPS drift, as these points were in a straight line.

It was a pretty full-on few days out in the field, but it was thoroughly enjoyable and the software is definitely in better shape for it. The real benefit of going into the field to work on this project was to get a really good understanding of how people do business, and what they need our software to do for them. If any of the TERN guys read this, thanks for making the trip an enjoyable and memorable one.

So here’s a list in no particular order of what we learnt from this exercise:

1. Consumer grade tablet PC’s really need to be put into a good case to protect them from dust and water. We didn’t destroy any on this trip, but it would only be a matter of time…
2. Interfaces need to be fast. This can be achieved through smarter workflows, quick link buttons and prepopulating as much data as possible.
3. Software that learns from the data that is being entered can adapt to really improve the speed of data entry.
4. The GPS in these devices is not accurate enough for the point intersect kind of survey, but more than adequate for general sightings and other survey types.
5. The consumer grade devices (Samsung Galaxy Tab, HTC Desire) we tested absolutely require a means of charging them whilst on site. Running the GPS non stop, and working the devices hard really takes it’s toll on battery life – we were seeing a maximum of around 5 hours runtime, and sometimes even less.
6. There’s a big difference in performance between devices, even with similar specifications. The HTC Desire we were using seemed to be much faster than the Galaxy Tab. On the other hand, the Galaxy tab’s larger screen made data entry easier.
7. Wifi hotspots can be very inconsistent. Our little 802.11g hotspot was so bad that we ended up using the ‘wireless hotspot’ feature of one of the Galaxy Tabs to provide our wireless networking.
8. Even if the data collection is marginally slower capturing it in digital form, there is a massive saving of time over entering it into a database from field sheets later.
9. Statistics being generated on the device as the field data is being collected can be really useful for capturing trends or patterns of what’s going on in the environment.

AJ

Contact me via twitter, email or leave a comment below.

The post Developers + Fieldwork = ? appeared first on Gaia Resources.

Well, that’s 100% true, we are both opensource advocates and developers, and developing platform specific code is something we tend to prefer to stay away from, however, be that as it may, people like Apple products. To be honest, the iPhones and iPads that we develop for are indeed pretty neat products in their own way. They focus on stability, performance and I would say they actually do provide a really good user experience. (As long as you follow the Apple way).

So does that mean that Gaia are now Apple Developers?

Both yes and no. The main reason behind our participation in the iOS developer program is for us is to wrap up our platform non-specific HTML5 applications using PhoneGap and provide a ‘native’ app for iPhone and iPad users to download from the App Store, which is a more natural and consistent process on the iPlatform.

So in conclusion, the aim of all this is to enhance the experience for the end users of our applications enabling them to interact with their devices in the way that they would expect.

And Apple makes another 100 bucks in the process…

AJ

Contact me via twitter, email or leave a comment below.

The post An Apple a Day appeared first on Gaia Resources.

The Department of Computing has been running project based units with industry partners since 2003 with the aim of providing their students with an opportunity to work on a large scale commercial software project as a team. This unit gives the students an opportunity to apply the knowledge that they have learned over the duration of their degree in a non-academic environment. Students participating in the project often have to very quickly learn how to manage a large software project, new programming languages and of course maintain a healthy team dynamic. The students were supported by Dr Tele Tan and Dr Aneesh Krishna from Curtin University with AJ and myself as their industry partners.

This year, the students were tasked to enhance Earth 2.0 by creating a mobile component that would

1. Download survey information from Earth 2.0,
2. Collect species observations while running offline in the field, and
3. Upload collected sightings, performing any final tweaks and species identification before releasing the data to Earth 2.0

From our perspective, any potential enhancement to Earth 2.0 from this project is far secondary to our primary goal which is to give something back to the IT community by supporting the university and guiding our future colleagues. It gives us an opportunity to keep in touch with the latest concepts being taught at university and it also gives the students the opportunity to learn from our experience in industry. One year is a long time in the IT industry and who knows, perhaps when they graduate we may be in the market for a sharp young developer or two.

If your company is Perth based and would like to know more about sponsoring a student project next year, you can contact Dr Tele Tan and Dr Aneesh Krishna for more details.

You can drop AJ, or myself an email, or leave a comment below.

The post Curtin University Student Projects appeared first on Gaia Resources.

Developers often say that the worst projects to work on are the ones where there aren’t a fine enough list of requirements before the commencement of development. Well, I don’t necessarily agree, having been a fairly strong proponent of agile methodologies for a while now. Requirements are important, but more important is communication and expectation management. The requirements will be pretty clear if you understand what it is that your customer does, how they do it, and you take the time to work through it with them.

When you work alongside your client, in the same office, even at the same desk, you have access to a unique resource that you’d be crazy not to make the most of. That resource is instant feedback. You can write a line of code, and get instant feedback as to whether it’s inline with the client’s expectations and requirements. Naturally, you can’t run an entire project like this, as it’s both draining on the developer and the client, however, I think it’s a really valuable exercise to very quickly ensure that you build a product that your customer wants.

Naturally, of course, there are a number of critical pieces to the puzzle that need to be sorted out before a developer runs off to perform a massive code sprint with their client:

• An agile framework – If it’s going to take the developer two hours to put a button on a screen in an interface, then rapid development with client involvement probably isn’t going to work.
• An indepth knowledge of the codebase – I wouldn’t run out to do this sort of thing with some code I wasn’t familiar with
• Version control – After all, you’re going to need to bring all the rapid cranked code up to production standard, and version control is going to tell you what actually happened. (And allow you to roll back should things go pear shaped).
• A clear understanding of the scope. The developer really should know what’s in scope, and what’s not… and for things that aren’t, well, there is a discussion to be had before making those changes.

During the week, the species loader codebase increased by 25%, there were about a dozen new screens added and various other requirements that would have otherwise been missed were implemented. The important thing here, however, is that the work performed was really in the critical areas of the software – the parts the client would be using most frequently and needed to work flawlessly. Now I’m sure some of you developers out there are thinking that this is cowboy coding and in some respects it is… except that when you get back to homestation, the use of version control, bug tracking and other software development tools allows you to review in depth all the work performed and ensure that quality is maintained as it’s checked back into the main codebase. Much refactoring is being undertaken this week to ensure code written during the sprint is of high quality and maintainable.

It was really a great experience to sit alongside the guys to continue development and the data loader we’ve built is a much better product after the exercise too. Working closely with your client is the difference between a product that matches the specification but ends up on a shelf somewhere, and a product that focusses on what the client’s problems are, and does the most important things well.

Email me directly here or find me on Twitter

The post Developing with your clients appeared first on Gaia Resources.

The concept of the new website pre-dates my employment with Gaia Resources, however not really much was done about it until a couple of months ago. I believe the conversation was something along the lines of the following:

• Mel: The website looks terrible.
• AJ: Well do you think you could do better?
• Mel: Yep.
• … half a hour later AJ receives an email with a bunch of concept art.
• AJ: Wow!
• It looks like she really could do better!

From that point, Ben (K) was enlisted into the team to do all the heavy lifting on the website work. Due to the dynamic components of the website, we decided that it would be good to use a full blown web application framework, and Django was selected as we have experience in it, it’s fast to develop, and of course, it’s opensource!

Here’s what Mel and Ben had to say about the process:

Mel :The team were in agreement that the old website was getting a bit old, with images and content needing to be desperately revised and updated.  It had served us well but it was time for a new design, one to reflect our capability profile and business cards layouts.  So the challenge began.  It has been a collaborative effort, with everyone getting a chance to have their say and give ideas on how the new website should look and feel.  It was also a huge learning curve for myself within the web building environment, finally finding out that a pretty design doesn’t transfer well over to the development side (my workmates can vouch for my frustrations after hearing my pained screams from the office all last week, “Why won’t you work in IE!”).  Hopefully the new design is something you will appreciate too.  This of course is just the first revision – we would love to hear your feedback and comments to be able to build an even better version two!

Ben: When I was first asked to redevelop the website and got handed Mel’s awesome design work, my first thought was “Oh no I’ll need to make this work in IE6”. Thank goodness that saner minds prevailed and we only support modern browsers. After that it was just a simple matter of coding it up using Django validating the HTML and CSS using the free online W3C Validators. There were a few highlights including integrating Type Pad AntiSpam with Django to protect our brand new blog/news comment system and integrating with the Twitter API. All in all it was a relatively painless exercise which I think is a testimony to the hard work put in by the Django development team and the general maturation of the web.

So in conclusion, we all hope you enjoy the new website, and look forward to hearing what you have to say about it… which you can do in the comments section below, Jim.

Email me directly here or find me on Twitter

The post Building a better website appeared first on Gaia Resources.

As most people will know, Microsoft has a pretty reasonable product called Exchange. Exchange provides an all-in-one solution for a company’s email, calendar, addressbook, tasks and several other collaboration needs. It also works out fairly expensive as a company grows, as you pretty much have to purchase a license of Microsoft Outlook for every new employee. Other issues we were finding with our proprietry solution were that it has been difficult to customize, configure and we were never really quite sure what has been going on under the hood.

Enter Zimbra Collaboration Suite… Backed by Yahoo, this opensource product provides not only email, but a rich host of services such as LDAP and user management (a replacement for Microsoft Active Directory), shared calendars, instant messaging, address books, file sharing and the list goes on. It even has a desktop application that replaces Outlook that’s just as easy to use and is extensible.

Making the switch was, of course, not a small task. Months of preparation and planning were involved, not to mention the server setup, but by finding the right community contributed information and resources we were able to get our new server up and running without too much hair pulling (yes, i have hair to pull).

So now that we’ve been using Zimbra, Zimbra Desktop and the web interfaces, how have we found it? Well, here’s what the guys are saying:

• Corinne: I like it, especially how it groups the whole email trail together automatically which makes them easier to manage and the inbox a lot tidier.
• Andrew: Automatically grouping similar messages together is awesome. Being able to save searches is also awesome.
• Tom: As I rely heavily on my email/calendar program to organise my work tasks, I was concerned there would be data migration problems and delays while I learnt the new tool.  However, I am pleased how efficiently migration occured and the speed I have managed to make good use of Zimbra despite having to slightly alter my work style.  There are many benefits to Zimbra that outweigh the initial unfamiliarity with the appplication.  There is no reason I would go back.
• Mel: You could get into the nitty gritty of the little special extras each contain,  but on the whole, both Outlook and Zimbra provide the same basic functions and both seem to do it well.
• Piers: It’s not a proprietary product, and the web client is great.

Naturally, of course, i’d better give the whole picture and tell you what else they’re saying:

• Corinne: Things I don’t like include that it is slower than outlook and that we don’t have those pretty propriety fonts
• Andrew: RSS support is terrible – Can’t import an opml file and you have to manually update the feeds. Attachments are clunky, you can’t drag in a file and downloading attachments takes to many steps
• Akeal: Outlook is still my preferred alternative, however now that some time has passed, I am used to Zimbra and it does the job pretty well. I also find it handy that I have the tab to access my Gmail account from inside Zimbra.

Personally, I find it comparable to Exchange/Outlook in capabilities, it provides better server management, it works on Windows, Mac and Linux and it’s spam and virus filtering is far superior to “Intelligent Message Filtering”. Finally, it gives me a sense of satisfaction to know we’re no longer locked into a closed platform.

At the same time as our switch to Zimbra, we also did a major network infrastructure overhaul too. Gone is our Microsoft Windows Server gateway/router, and in it’s place is a shiny new, low power, FreeBSD-based router/firewall. Unfortunately, at the time i commissioned the new machine we were having issues with our ISP which made it look like the network was running a lot slower… Fortunately, Amnet were able to sort out the problem and since then our link to the world has been performing really well. The new server provides us with much more flexibility, particularly in the areas of network address translation (NAT), complex routing and fault tolerance and we’ve now got our own local transparent proxy to minimize our network traffic usage (somewhere down the line that lowers power consumption and carbon emissions…)

Speaking of carbon emissions, the final change we’ve made here is a move to virtualized servers. Whilst we still have a few dedicated servers around, we’ve started to host quite a few of our development, testing and corporate infrastructure servers in virtual machines. On one of our grunty machines we’re hosting five (5!) virtual servers including 2 development boxes, a test server and two corporate infrastructure servers. Taking into acount that the average server puts out around 3 – 4 tonnes of carbon emissions every year, by consolidating these onto a single machine we’re saving up to 16 tonnes of carbon emissions each year! (Of course, this is all theoretical, our power here is Green Power, so we’re already offset).

You might think that performance would be terrible, but actually, the host machines have never gone above 37% CPU utilization, and it has plenty of memory. The beauty of the setup is that it’s pretty rare for the machines to all want to use the full power of the machine simultaneously. This means that the virtual machine hypervisor can give each virtual machine more resources when they need them, but scale back the resources when they’re idle. Having a nice big machine with 8 logical cores and 12GB of memory also helps.

So, it’s been an interesting start to the year, network wise. We’ve still got Microsoft Windows on a lot of our desktops, although there are a few linux workstations starting to pop up around the place. Unfortunately, Microsoft Office is still not going anywhere fast, with the majority of our clients using it, meaning that we have to use it to maintain compatibility, but hopefully, with the release of OpenOffice version 3.2 today the opensource compatibility will have improved somewhat and we’ll see more organisations starting to use it.

I’d love to answer any questions you have about our delvings into opensource, so email me here or send me a message on Twitter.

The post Breaking the shackles of proprietry collaboration appeared first on Gaia Resources.

So time for a quick teardown. The new Apple iPad is a lightweight, long running, internet device. It’s ever so slightly larger than the paper notepad that I carry around with me – about 2/3rds of a sheet of A4 paper and is about 14mm thick. In terms of weight, it tips the scales in at around 700g. Of course, like most things apple, they’ve gone with a custom operating system (based on apple iPhone OS) and very proprietary hardware. In effect, the new iPad is essentially a larger iphone.

In terms of environmental impact in manufacture, packaging and efficiency, Apple has alway been pretty good. It is arsenic, mercury, BFR and PVC free, has an LED backlit LCD display and comes in a minimalistic cardboard package. The device battery lasts some 10 hours whilst connected to wifi, and uses a 10W power supply. In fact, you can even charge it up over a USB port.

What does it all mean?

Since the iPhone was first introduced a couple of years ago there has been an explosion in the amount of data that people are collecting. For example, I use my iPhone to take pictures, records notes and thoughts, collect data about my sleep patterns and capture travel routes. For a couple of hundred dollars, the iPhone presents probably the best value for money portable sensor pack available. Well, the iPad has all this too, but now with a useable amount of screen real-estate. What this means is that now we have available the first really useable field data collection tool. And because it has been backed by Apple, they’re going to be everywhere.

Finally, it shows once again the benefit of using a web-based platform for modern application development. Applications available on the web, such as Twitter, Facebook and Google Apps all work with the iPad now. Come to think of it, so does Earth2.0

Email me directly here or find me on Twitter

The post Apple’s Latest: The iPad appeared first on Gaia Resources.

When I logged into Google Wave for the first time, I took a quick look around and decided to myself, “An interesting distraction, but it doesn’t look useful just yet”. As time went on we got our first round of invites here at Gaia Resources which were eagerly snapped up by the rest of our staff and it was then that the benefits of Wave started to become apparent. Once waves reach a certain critical mass they seem to explode with creativity and often the thread will spin off into various tangents that wouldn’t be possible with other forms of communication.

It is this randomness that is both Wave’s best and worst attribute.

As a brainstorming tool, Google Wave fosters active participation and creativity. As a business tool, it would be all to easy to become distracted and head the conversation in the wrong direction. I suspect that as people become more comfortable with the technology the tendency for randomly commenting throughout a wave on its various blips will also calm down a bit.

The second really powerful (and as of the moment under exploited) feature is Google Wave’s gadgets. A gadget is kind of like a smart block that can be added to a wave to perform practically any function. For example, if you need to run a teleconference you can add a teleconference gadget. Need to run a quick poll of peoples opinions? No problem, add a polling gadget. Need to show people the exact location of a landmark? Add the Google Maps gadget.

Google have released to developers the API for programming gadgets so it’s only a matter of time before we start to see all manner of gadgets that do everything from composing poetry to displaying the contents of your internet enabled fridge.

So in summary, Google Wave is a promising tool that is going to become more and more useful as time goes on. Let me be clear, though: the Google Wave preview has lots of bugs and probably isn’t ready to be part of my daily work toolset… just yet. Once they’ve ironed out the all too frequent crashes, lockups and general sluggishness of the platform, Google Wave is set to turn into a really powerful tool.

E-mail me directly here, find me on Twitter, or Wave me at ajones17221@googlewave.com

The post Google Wave: The next big thing in collaboration? appeared first on Gaia Resources.