The Perth Spotfire Meetup was held a few days ago and it was a positive experience to bring up the topic of Cubes and then further discuss with others their findings.
Sheldon and Brendan from The Frontier Group opened the topic with a quick presentation. Even before that was finished we were into the discussion of integration pros and cons and the technical reasoning around these systems.
The meet up now hosted in a fairly lofty meeting room provided by TIBCO was filled with people which shows an interest in the product and a growing community.
If you have any suggestions for meet up topics or are generally interested in Spotfire and its analytics capabilities, definitely get in touch with Matt Lambie at The Frontier Group. We are happy to discuss the rapidly changing space and the possible solutions around the area of business intelligence.
As many of you know The Frontier Group has recently relocated to a brand new office in the heart of the Perth CBD. Big things have been happening for us this year and we realised we had outgrown our office in West Perth and that if we wanted to keep growing and keep our clients and team happy we would need a shiny new office to do it all in.
The new space is a fantastic open plan office on the corner of Barrack and Hay St, a short walk from public transport, great coffee, good food and of course closer to our CBD clients; Rio Tinto, Woodside and BHP.
But we knew we wouldn’t feel at home until we threw an office warming party. On the 20th June we opened our doors to family, friends and clients and celebrated the newest phase of The Frontier Group. Friend and client Bar Pop turned the space into a trendy pop up bar for the evening, the tunes were pumping, the turnout was fantastic and it was heartwarming to see so many people celebrating with us. We had a total blast and we hope everyone else did too.
If you couldn’t make it don’t worry, check out the photo below from Friday night.
At The Frontier Group we have been working with TIBCO for quite some time and have been an official Partner for over a year.
In recent months we made history with TIBCO in Australia and New Zealand by having the most certifications of any TIBCO Partner. We’re also the only certified TIBCO Spotfire System Integration partner in Australia.
In light of that, we’d like to congratulate Matt, Courtney and Darren on becoming our latest certified team members.
PetRescue (petrescue.com.au) is a charitable organisation on a mission to save Australia’s abandoned pets. They have brought hundreds of rescue groups together under one website to create a dominant unified web presence and significantly improve the chances of people finding the perfect pet.
We invest heavily in promoting the adoption option to millions of pet lovers, and continue to offer our services, programs and online resources for free to hundreds of shelters, pounds and rescue groups Australia-wide.
When PetRescue first approached us they had a great model for how they wanted to work but needed to grow. Our first round of work helped to revamp the website and also give it the robust growth potential they needed. Our design work was kept simple, clean and all about the pets. The ability to grow revolved around a fresh rails app and a much bigger architecture to support it.
We had the chance to test this growth potential thanks to a Whiskas campaign that required our systems to withstand thousands of concurrent hits per second. We managed this and more without our servers even flinching thanks to some clever caching and a well structured architecture that was living on Amazon’s cloud servers.
Since that initial round of work, the numbers of visitors and adoptions have been increasing and PetRescue have managed to help rehome a staggering 200,000 animals across Australia with a further 9500 currently sitting on the site ready for new homes.
With such a great experience we were so excited to recently get a call regarding some more work. To enhance their already great offering, the PetRescue team had the idea of providing video content of prospective pets. We saw this as a great opportunity to leverage Amazon’s new video encoding capability named Elastic Transcoder and in a fairly short space of time we are proud to have launched this feature on the site.
This site has been a great exploration of Amazon services for us and with a little tweaking, our ability to template, rollout and spin up many different services has been very positive.
We would also like to congratulate John Bishop, PetRescue’s technical lead who has been working with us closely and received multiple “40 under 40” awards for his great work with the site.
Photo From: Business News WA
PetRescue is very a worthy cause so if you have any interest in an adorable pet, check out the site or have a look at their facebook page.
As part two of our series, Tony Issakov offers a few thoughts when developing on RubyMotion.
Whilst I spend a lot of time in a management role, I’m a developer at heart that cannot stop developing. Here’s a few things that I’ve come across in the RubyMotion space that may be of use.
1: Know the code you are building on
RubyMotion is a relatively young space that is filling quickly with enthusiastic Ruby developers. New gems are coming out regularly to carry over what we know from our native Ruby world and also to make new iOS capabilities more comfortable to access.
One thing to be aware of is that being a new space there are some fairly fresh pieces of code being integrated into common use and some of them haven’t had much time to mature. For this reason I suggest taking a moment to get to know the gems you are about to use.
Just as with any code, Github gives us a good place to start, checking out the most recent commit activity, the scale of the issues and hopefully checking that there’s a test suite. Whilst testing isn’t as fully fledged for RubyMotion, an attempt to test is a great start.
Reviewing how code is written has also been very informative. If you want to get some diverse exposure, start looking through BubbleWrap, the ever growing mixed bag of RubyMotion functionality. You can see anything from how to leverage the Camera through to observers with the Notification Centre. It gave me some ideas as a ruby developer of what iOS topics I needed to start researching.
2: Memory Matters
One major change moving into the RubyMotion space from a Rails one is that it’s no longer a stateless environment, pages aren’t a regularly discarded entity and what you do over time can mean something. If you don’t know about reference counting in iOS and the commonly mentioned ARC, it’s worth doing a little homework to understand what RubyMotion is doing for you. Apple provides some documentation explaining memory management, here.
One example of why it’s good to know this is I hit a show stopping moment when I started attaching view content from an 3rd party framework to my own controller objects using instance variables. The external library counted on the releasing of those objects as the app moved through multiple sessions and I was inadvertently retaining them. This ended up in some interesting crashes and the word ‘release’ is a real give away.
A protip here (offered initially to me by Jordan Maguire) was to leverage the dealloc method. If you override a class’s dealloc method, clear up your instance variables, put in a bit of logging whilst you are there and then call out to super, in theory your RubyMotion console should give you a bit of feedback that your app is being healthy about releasing it’s memory.
Another key object to figure out for this topic is WeakRef.
The need for WeakRefs comes up when you start passing delegates around and begin to form cyclic references which if not handled well, can in the least cause memory leaks. Wrapping an object in a WeakRef object gives you a programmatic way of ensuring you release an object and again look to the console for that dealloc feedback.
3: Think ‘Performance’
One of the major benefits of RubyMotion is taking a lot of ruby ideas for making code easy to write. One catch is that a lot of layers of abstraction can create the opportunity for a performance hit.
We saw this first hand when first trying gems like Teacup (a gem for layout and styling). When the gem was pretty young, people using it noticed their apps start to grind and scrolling through tables suffered a stutter. This came down to doing things in a programmatic but performance expensive way when styling table cells. From what I’ve seen many of these issues have been resolved and that has come down to both gem improvements and better patterns for developers applying code in a performance friendly way.
One paragraph that really stuck in my head on this topic was reading through the Queries section of the CDQ gem README. CDQ is a slick Core Data helper and the paragraph reads:
Core Data is designed to work efficiently when you hang on to references to specific objects and use them as you would any in-memory object, letting Core Data handle your memory usage for you. If you’re coming from a server-side rails background, this can be pretty hard to get used to, but this is a very different environment.
This sums up my very first moments of walking into RubyMotion from rails which was iOS persistence is handle by Core Data therefore Core Data equals ActiveRecord. We keep pushing the point but it’s not that Core Data isn’t ActiveRecord, its that things like persistence and what it means to each environment are very different.
4: IDE is not a bad word
Vim versus Emacs? How much finger twister can you play to do fairly amazing things with your editor? I’ve been sucked into this a few times over the years and will admit I find myself in the vim space largely because it was the editor I was raised on. In recent times I followed the Textmate to Sublime migration too. For a time though I found myself in the Java community working with IBM’s Application Developer and that’s where I came to terms with what an IDE is.
When I started to explore RubyMotion and got sucked into the “What editors can I use next?” game, I dabbled with RubyMine and was a little surprised. IDEs for me in the past have meant memory bloat and user interface lag but the JetBrains guys have done a great job optimising resource usage and letting you customise behavior.
Why bring this up for RubyMotion? For many who are looking for some form of visual assistance, a nice refactoring capability, a debugger that is interactive, a spec runner that is visual, this might be a good tool for you to consider to give you a safety-net as you develop. This is absolutely not for everyone but I generally take all the help I can get and regularly swap back and forth between command line and visual tools depending on the task at hand.
5: The simulator is not the device
The iOS simulator is rather amazing in what it offers. A highly performant version of the device that you can swap between device types, screens, resolutions and even simulate events with. With all this it does lure you into believing it’ll be an effortless trip to the device but we found there are a few catches.
The first was that sometimes the simulator outperformed the phone and this is due to the simulator having the full resources of the host available to it. A few of our animations that were smooth on the simulator stuttered slightly and it was during a series of changes that it occurred.
Another situation was when using external Objective C libraries, it’s possible for the library to have different branches of code depending on the environment meaning that the code you run in the simulator is not necessarily the code you will run on the device. In one extreme case we actually needed to set some custom build flags for the app to even compile for the device.
So the recommendation here is run on the device and frequently enough that if the app has some unusual explosion you aren’t left wondering which of the many gems you just added or commits you just made has cause the issue.