We are hiring. Front End Developer - AngularJs

4 Jul 2014
by Michael Cindric

We are looking for a AngularJS developer to join our team. We are based in the Sydney CBD with a great team and environment

Required skills and experience:

  • Angular.js Experience/Exposure

  • Strong JavaScript Skills

  • jQuery

  • HTML5

  • CSS3 - LESS or Sass

  • Excellent communication skills

Bonus Skills:

  • RubyOnRails

  • NodeJS

  • Experience with any other JS Frameworks such as Knockout.js, Backbone.js, Underscore.js, Require.js Ember.js etc

So if you think you have what it takes get in touch at jobs -AT- sentia.com.au

Building a Social App for 2014: Do you stand for privacy?

14 Apr 2014
by David Evans

Facebook has turned 10, and Twitter is almost seven years old. Despite their behemoth user bases, new social apps find space to create their own success every year. Thanks to the NSA revelations, 2013 was the year that many web users woke up to their privacy situation. While privacy is clearly not yet the #1 factor (WhatsApp is not the pinnacle of privacy), it’s worth considering what your stance will be at the earliest stages of idea development and planning.

Users are becoming more aware of the pitfalls of major social networks, old and new:
- Facebook records everything you type into a status update field, even if you decide not to post it;
Read on Slate
- SnapChat's records of users' phone numbers and usernames are not as secure as we might like;
Read on TechCrunch
- Facebook Like/Share and Twitter Follow/Tweet buttons track web browsing habits of individuals, even when they're logged out of the social network, even if they don't click the Like or Share button.
Watch on YouTube
I explain how to avoid this tracking at the end of this post!
- Google and Yahoo's internal fibre networks have been tapped, with millions of records stolen per day
Read on the Washington Post
- Private search (DuckDuckGo, startpage.com, disconnect.me & others) and other privacy-enhanced apps have had considerable attention and success
Read on The Guardian

Now, consider what your potential users are thinking:
- Do I want to sign up, with my real name and photo, for another social network that will try to learn about my habits and interests, link that information to my identity and monetise it? With whom will they share my data, and what will I gain and lose from this sharing?
- Do I trust another site that has the answers to my privacy concerns buried in the legalese of their privacy policy?
- Do I trust myself to get the privacy settings right when they are complex, convoluted and defaulted towards sharing more?
- Do I want to Facebook/Google login to another service, connecting all of my actions in that service to my real-world identity?

Think about what kind of company you want to create over the next several years. Do you want to sneak around or work against your users’ privacy interest to emulate what has been a successful business model, even as public opinion turns against some aspects of that model? Or do you want to create a company that takes the lead on privacy and charges customers to solve worthy problems?

P.S. Here’s how to avoid your users being tracked when you want to link back to your social pages, or allow them to quickly share your content:
You don’t need Facebook Like/Twitter Follow buttons. Instead, provide links to facebook.com/yourapp and twitter.com/yourapp. Plain links will not require you to include Facebook or Twitter’s javascripts, allowing you to guard your users' web browsing habits from those companies. You can style plain links any way you like, and your page will load faster without the extra scripts. While Facebook Likes and Twitter Followers may help to engage your users, nothing will save you if you don't offer your users a mode of communication or expression that adds value to their lives.

In the case of sharing content, Facebook Share/Twitter Tweet buttons can also be replaced by links such as https://www.facebook.com/sharer/sharer.php?u=http://yourapp.com/your-content and https://twitter.com/home?status=Your%20tweet%20text%20http://yourapp.com/your-content.

Mobile developer @ Sentia

9 Apr 2014
by Michael Cindric

We are looking for a mobile developer to join the Sentia team.

If you think you have what it takes to become one of the team at Sentia, well, we want to know about it!

We are looking for a mobile developer with the following skills

Key Skills

  • Experience in iOS development

  • Experience in Android development

  • A talent for communicating ideas, issues and solutions in a team environment

  • Excellent English communication (verbal & written)

If you have the skills please get in touch by sending us an email at jobs -AT- sentia.com.au with your CV along with a link to your GitHub profile along with any examples of your work.

Reasons You Should Build an iOS App Natively

10 Feb 2014
by Michael Cindric

These days, it’s imperative that your business has a mobile presence. Without it, you’re missing out on almost 20% of your potential traffic. Instead of going for HTML5, offering your customers the opportunity to download your company app through Apple’s ecosystem is a great way to leverage this traffic.

Difference Between HTML5 and Native Apps

First things first, let’s quickly recap the concept of what sets a native app apart from HTML5 applications. Native apps are device-specific, such as for Android or iOS (Apple). This means that the program has been specifically tailored to work with a given operating system, as well as a smartphone’s unique features (such as the GPS and camera).

HTML5, on the other hand, is a web-based programme that (theoretically) works on any given smartphone or tablet via the device web browser. Proponents of this method champion the fact that you only need to code something once and it works on absolutely everything. However, it’s not always all it’s cracked up to be.

iOS Apps Perform

When it comes to sheer revenue figures, it’s clear that an iOS app performs very well on average. This is due to the fact that Apple iOS users are much more willing to whip out their credit cards. Over 400 million accounts are tied to active credit cards – just a small slice of this market can be very lucrative indeed.

HTML5, on the other hand, offers no marketplace to offer your app. It has no option to monazite it as a standalone product. If your company can offer a service through an app, then it’s always preferable to be able to sell that service packaged within a native App that can be sold at a small fee (even if you’re not doing so yet).

In addition to the tendency to be willing to pay for apps, Apple customers are also happy to spend on in-app purchases as well. So if you’re selling something online, it’s a good idea to offer users a solution that is completely tailored to their environment. Even the slightest alterations can mean the difference between a successful selling machine and a worthless dud.

User Experience

When it comes down to it, not a single developer is going to deny the fact that native apps simply work better than their HTML5 counterparts. This is because the app can leverage the nuances of each operating system, delivering a customised and innovative solution.

Even Facebook’s Mark Zuckerberg agrees that HTML5 just doesn’t cut the mustard just yet. In September 2012 he said:

“The biggest mistake we made as a company was betting too much on HTML5 as opposed to native. It just wasn’t ready.”

This goes to show that while HTML5 will save on production costs, it has the potential to severely hamper user experience. If your mobile offering is critical to your business, then it’s worth spending that little bit extra

HTML5 = Security Risk

Source code in HTML5 is much easier to access, which means that it can be hacked. Native apps, on the other hand, are encrypted to guarantee that cached data is always secure. When holding any sort of sensitive information, native apps are the safe bet.

While HTML5 (or similar) may one day be the superior choice, we don’t see it happening anytime soon. Browsers simply don’t give a standardised base from which to work on. It seems like other developers agree, as interest in HTML5 suffered a noticeable drop in Q4 2013.

8 Benefits of Using Ruby on Rails for Web Development

6 Feb 2014
by Michael Cindric

It’s safe to say that Ruby on Rails is hot at the moment. But is it just a trend based on a buzzword or is it really a legitimate choice for developing web applications and websites? In this guide, we’re going to give you 8 benefits that set Ruby on Rails apart from the competition.

1. It’s Perfect For Web Technologies

Fits like a glove. Like peas and carrots (Forrest Gump anyone?). Idioms and 90s movie references aside, let’s just say that Ruby on Rails is absolutely ideal for building web applications.

The great thing about it is that you can get a working prototype up and running extremely quickly. Checking the feasibility of a project is made much easier because of this. In addition, cracks in the scope and direction of a web application can be fixed early on in the development cycle.

2. Saves Money

Whether you’re the project lead or the client, no one is going to complain about this one. To put it simply, Ruby on Rails can cut significant chunks out of web project. The framework is 100% free and runs on Linux, which is also open-source. It’s also easy to work with from a developer’s perspective.

If you’ve migrated from ASP and Microsoft Windows we expect a sincere “hallelujah!” from everyone involved. While these are legit options for some projects, they can be prohibitively expensive.

3. Saves Time

In addition to being a cost-saving technology, Ruby on Rails can turn some developers from lumbering sloths to rapid code monkeys. Not only does it allow you to move from the planning stages to actual development very quickly, it’s also easy to handle compared to other technologies.

4. Active and Helpful Community

The most successful and popular web applications are often open-source. Content Management Systems such as Drupal and Wordpress have thriving communities that allow them flourish, and much is the same with Ruby on Rails.

The community is full of developers that are constantly improving code and helping others on their projects. This means that if you need a given piece of functionality, there’s every chance that someone else has built something similar before or is willing to help you fix any issues you may have. You’ll still need a capable team to work with the code as it’s not all plug-and-play, but it definitely helps a project move forward.

5. Project Not Handcuffed

You’ve had a fantastic website or application built and everything works as expected. Months (or even years) later, you run into an issue that you didn’t know about or you decide you want to add functionality.

What happens? You find that the company that built the original application no longer exists, or the developers that worked on the project are no longer part of the company. No one knows where the code begins or ends. The result is a painful exercise of expensively rebuilding everything from the ground up, or getting the issues fixed on the original platform at ridiculously inflated costs.

Ruby on Rails, on the other hand, follows coding conventions that make it simple to go from one developer to the next. It’s clean, it’s easy and everyone uses it. Your hair will be thankful, as you’ll no longer be pulling it.

6. Build Your Own Plug and Play Apps

The beauty of Ruby on Rails is that you can create your own building blocks for plug-and-play functionality. Now, it’s on as simple as snapping your fingers, but it’s much easier to do it with Ruby on Rails than with any other technology on the market today.

This means that you can take elements of your current custom application and use it in your future projects, instead of having to build the entire thing from scratch. Ruby on Rails allows your apps to be expandable and multi-purpose.

7. The Big Players Use It…

You know that there’s something seriously right about Ruby on Rails when reading the list of companies that currently use it. Let’s have a look at just a small selection:

  • Hulu
  • Groupon
  • LivingSocial
  • Twitter
  • Basecamp
  • Realestate.com.au

All of these companies are not only completely different from one another, but also offer complex functionality and services. What makes it all possible? Ruby on Rails.

8. …But You Can Use it Too

Ruby on Rails is not only ideal for the larger companies, but it’s perfect for startups or local businesses as well. In a web landscape where you need to stand out to make something out of your project, Ruby on Rails allows your web application to break free from the standardization of template solutions at a cost that won’t cripple your bottom line.

5 Reasons Why You Should Use Ruby on Rails for Web Development Over PHP

6 Jan 2014
by Michael Cindric

PHP or Ruby on Rails – that’s the question that’s gripped developers in recent years, though the tide is definitely turning in favour of the latter. You may be surprised, considering some major websites run on PHP (such as CMS stalwarts like Drupal and Wordpress). So what’s the deal?

Ruby on Rails is superior in so many ways that we’d need to have a sit-down meeting to run through them all. Instead, we’re going to give you the top 5 reasons why it’s the superior solution for 2014 and beyond. You can always pop by our offices and hear about the rest!

The Framework is Mature

Ruby has the distinct advantage of being built on solid foundations – it’s much easier to get a high-end product online quickly and efficiently. Not only that, it beats PHP in its capability to support maintainable solutions that are build on solid code.

The mature framework also means that you can get your hands on juicy open source freebies that are extremely powerful. You’ll be surprised by how far you can get on things that have already been built with others – this doesn’t mean it’s all plug and play, but it does shave a decent amount off initial costs.

PHP Is Not Liked By Developers

The web development community has reached the end of its tether when it comes to PHP. Programmers simply find it frustrating to use. The reality is that most web developers prefer using Ruby on Rails these days.

It’s not just a matter of preference or what’s ‘hot’ right now. Ruby on Rails is superior and developers are making that clear by ditching PHP and switching over in droves.

PHP Makes It Easy to Write Bad Code

The problem with PHP is that it’s too easy to pick up. Its rules are relatively lax, meaning that you can get a simple web application up and running without much trouble. The problems crop up when you need to make alterations, when random bugs are caught, or when the project needs to be scaled or added to. Then it gets expensive and time consuming.

Ruby on Rails, on the other hand, makes it much harder to write bad code. It means that the chances of making a mess of it are minimised. While we’re not saying it’s impossible to write good code with PHP, it does let quite a lot of terrible samples through the door.

Ruby on Rails Has a Steep Learning Curve

Hold on a second – we can hear you say – I thought this was meant to be a list in favour of Ruby on Rails? How is a steep learning curve a positive feature?

This one ties into our point about PHP being too easy to pick up. When you know PHP can be done by anyone, it becomes much harder to discern whether you’re landing yourself a decent web developer or a hack that can just about piece things together. If you get the latter, prepare yourself for a world of hurt.

Ruby on Rails, on the other hand, has a learning curve that demands proper code and standards. You can’t get away with the same stuff you can do with PHP. This in turn means that a Ruby on Rails project is usually elegant, clean and extensible. This saves time, money and plenty of headaches in the long-term.

PHP Is No Longer Leading the Line

Around ten years ago, PHP was the language to go for when it came to web projects. We’re pretty sure that almost every cutting-edge start-up used PHP to power its website. But it’s not 2004 anymore.

PHP has since stagnated and is no longer the chosen path for innovative technologists. This means that if you want to be involved with the most advanced features and open-source code that is truly trailblazing, then Ruby on Rails is the way to go.

We’re not saying that you should simply opt for Ruby on Rails because it’s ‘cool’. Rather, we’re seeing a market shift that is reflecting the reality of the benefits of Ruby over PHP. We expect this trend to continue in the coming years – there’s no reason not to jump on the bandwagon.

Send a Script wins at 2013 Australian Mobile Awards

21 Nov 2013
by Michael Cindric

Very proud moment for the Sentia team with our client "Send a Script" taking out top honours at this years Australian Mobile Awards. Sentia developed not only the web application platform but as well as the iPhone Application and currently has the Android Application in development.

The Send a Script iPhone app allows users to send photos of their prescriptions to selected pharmacies and then be notified when they’re ready to be picked up. It can also locate the closest pharmacies to users saving time and effort in those much needed times

Sentia was also the only developer to have 2 applications at the awards with "My eVault" just missing out.

Doccy iPad app goes live

19 Nov 2013
by Michael Cindric

Sentia's service Doccy has had it's iPad application approved and now ready for download on the Apple iTunes Store. You can download it here

Doccy is the easiest way to create, send and share documents and now its even easier to do on the go with the Doccy iPad app.

For more information on Doccy visit the website

Choosing a payment gateway for FitUsIn - eWAY or Braintree?

17 Oct 2013
by David Evans

FitUsIn hired us to implement the eWAY payment gateway in their Ruby on Rails app at www.fitusin.com. After finding out the cost of opening a merchant account, they asked us to switch from eWay to Braintree, giving us a direct comparison of the implementation experiences at this point in time. We found that the eWay implementation is more difficult than it needs to be, with Braintree having an easier experience. Here's why:

The eWay Ruby sample code works, but is not a realistic part of a Ruby on Rails application. It contains unused ActiveMerchant sample code, which suggests that the eWAY gateway in ActiveMerchant is up to date & supported. It exists, but it has a few bugs and eWay support staff are not familiar with it, nor does it seem that eWay contribute code to it.

ActiveMerchant is our Ruby gem of choice because it provides a universal implementation for dozens of different payment gateways. When implementing eWay, we found over several hours that the "successful transaction" page proved very elusive. We investigated our code from all angles, eventually tracing data through the class in the gem which connects with the eWAY API. It turns out that the ActiveMerchant eWayRapidGateway class is not perfect, but could be fixed with a little open source work. I advised eWAY support (who always did a great job) that their company might get more business if they hired a ruby developer to improve the class, rather than relying on the open source community.

After fixing the eWAY class in the ActiveMerchant gem, FitUsIn finally had checked all the boxes on their NAB merchant account application form. Only then did NAB advise them of the full cost of opening and using a merchant account. The cost was significantly more than alternatives such as Braintree, cutting into their margin - so they decided to switch.

Switching to Braintree took roughly an hour, because we'd already implemented ActiveMerchant. A fresh implementation may take longer (and you'll also want to consider using the excellent Braintree gem). As mentioned above, ease of switching gateways with ActiveMerchant is one reason we favour it. The Braintree ActiveMerchant class is well supported, with everything functioning nicely. The Sandbox is easy to use and the support are responsive and informed. It should be noted that the Braintree payment settlement process is a little different, with no merchant account required.

While clients and their developers should consider all payment options together before each implementation (Stripe is in an Australian Beta), let our experience serve as a heads up for what may lie ahead in a Rails/ActiveMerchant project today.

Customising the Magnific Popup Lightbox in your Rails App

23 Sep 2013
by David Evans

For those not familiar with the term, a Lightbox is a javascript modal used to display previewed content front and centre.

Our Send A Script Rails App uses Lightboxes to show doctors' prescriptions sent from patients' iPhones to a pharmacy for pre-filling. These prescriptions can be tricky to read and can be sent from the iPhone upside-down when the photo is taken flat and the gyroscope loses its orientation.

What our Rails app needed was a Lightbox that allowed rotation of the doctor's prescription & expanded to fit the screen (responsive). I couldn't go past the stunning Magnific Popup, which had even been packaged in a gem for use with Rails' Asset Pipeline. The only thing missing was the ability to rotate images, so we built it. Here's how:

  1. Install the gem as per the GitHub documentation
  2. Apply the Javascript to the image element.
  3. Append a rotate button to the caption.
  4. Use the "open" callback to run javascript only when the Magnific Popup Lightbox is opened.
  5. Create a variable to store the angle of the image.
  6. Create a function to increment the variable by your desired angle & apply it to the image, upon clicking the rotate button.

$(document).ready(function() { // Begin Step 2
    zoom: {
      enabled: true,
      duration: 300
    image: {
      verticalFit: true,
      titleSrc: function(item) {
        var caption = item.el.attr('title');
        return caption + ' &middot; <input type="button" value="Rotate" class="rotate" />';  // Step 3
    },  // End Step 2

    callbacks: {
      open: function() { // Step 4
        newangle = 0;  // Begin Step 5

        $('.rotate').click(function() {

        function next() {
          newangle += 90;    
          if (newangle >= 360) newangle = 0;      
          return newangle;   // End Step 5

The result:

Have an idea?
Get in touch