I’ve recently started doing some Android development, and its been a ride with many ups and downs. Starting from day one, I had a feeling that Android development was going to be something that I enjoyed and would come naturally to me. My first day of Androiding was also the release day of Android Studio. How can I be given a better omen than that? Unknowingly I must have shot the albatross because the next few days were not a good experience. My computer can handle most applications I throw at it. It can handle RubyMine, PyCharm and any other IDE I have tried; but Android Studio was something else. Within fifteen minutes of installing Android Studio and running an emulator with a test app, my computer was a hot pocket straight out of the microwave. After another ten minutes my computer had overheated so much that it decided to turn off. So it was clear that I could not run Android Studio with an emulator. Next I tried using my own Android device to take off some of the stress on my computer. This was better, but only slightly since my computer turned off after about 45 minutes of this. After many abrupt shutdowns, I finally reduced myself to using Eclipse. This was less than ideal since Eclipse is an old IDE and its age shows (not in a good way); and on top of this I had to be careful with the number of additional programs I was running. It became so unbearable that I finally decided to buy a new computer. I can now run Android Studio and an emulator relatively easily, but I still think its ridiculous how intensive Android development is.
Now the development environment is certainly not the only thing to judge Android development by. There is also the actual programming side of Android. This has been much more enjoyable. The support for Android is very good in my opinion. Within a week Sen and I have been able to create a proxy server to handle requests, cache data in a database and play around with animations. Android makes it accessible to do these things, where as on the iPhone things like a proxy server are much more difficult. iPhone development does have a much better layout creator, but it is still entirely possible to do most things in Android. I have little experience with the languages used in Android development (Java and XML) but they were easy to pick up. The one big issue that I always hear about is that it is difficult to develop Android apps because there are so many different devices, but I have yet to encounter this problem (fingers crossed). Overall, developing Android apps has been an enjoyable experience thus far and I hope to use it in more projects in the future.
Cameron Ramsey, Junior Developer
Twitter has been making a lot of news lately. One of it’s biggest announcements of late is Fabric - Twitter’s new development platform. Fabric is an attempt to re-establish Twitter’s rapport with the mobile developer community, and become an integral part of the mobile internet, a position that has up to this point been held almost exclusively by handset makers and operating system developers. Twitter’s strategy, build a set of tools that developers actually need to tackle difficult problems, and make them really easy to use.
Fabric currently consists of three software development kits that developers can use within their apps to take take of things like monetization, user authentication and debugging.
- Mopub is an advertising platform that helps developers build native ads
- Crashlytics is a software debugging and analytics tool
- And Twitter, a distribution tool that allows developers to take advantage of twitter sign-ins, native tweet embeds, and Digits, the new phone number-based login.
One number to rule the world
Of all the new tools included in Fabric, Digits has gotten the most press. Digits gives developers a way for users to sign up for new accounts using just their phone numbers. Doing mobile sign on well is actually quite difficult, and can be expensive at scale given the per unit cost of sending SMS text messages. Multiply that by thousands, or millions, of texts across multiple countries and the costs quickly start to add up. Twitter is offloading that whole process onto its own system: giving developers the ability to add in-app SMS registration by just adding a few lines of code, and it’s covering all the costs. Digits is ideal for new apps from companies users may not be familiar with. Being able to sign up without creating a separate account makes it easier to onboard new users, increasing your chances of building a meaningful user base for your app.
What is Flurry, Google Analytics and Testflightapp had a baby?
Well that baby would probably be called Crashlytics. When Twitter purchased Crashlytics in 2013 it was not entirely obvious what they planned on doing with the error-checking and analytics platform. Crashlytics has clearly found a home in Fabric. Crashlytics helps developers make sense of crash reports, and diagnose the severity and scale of their application crashes. Other features include mobile analytics (Answers) and the new beta distribution capability that lets developers recruit testers from any platform, just by sending an email.
Twitter has brought together a suite of powerful tools for mobile developers to make building great apps a little easier. Whether or not it will be successful in it’s long term goal of finding a place at the heart of the mobile Internet remains to be seen. As with any quest for world domination there are bound to be some bumps along the road. In the meantime, Fabric is well worth the price of admission - free!
Matt Park, Marketing Consultant
Ruby is an incredibly powerful language to program in, and when you use the Ruby on Rails framework it becomes very easy to do things like build websites with databases. It becomes so easy that for the last year I have been able to put out an amazing amount of work. But it’s not all about how much work gets done, it’s also about the quality of your code.
I reached a point recently where I looked at some of my old code and hated myself. Not just my past self, but my current self as well. I knew if I needed to do that work again I’d have to do it the same way. There was obviously a better way of doing the work, and I realized I didn’t know it. So, I did what any programmer should do in that situation… I spent a week reading the manual.
The biggest struggle I had with reading the manual after having already worked with Rails for the last year was forcing myself to re-read what I already knew. If I just skipped a section I ran the risk of missing key information about how things worked together that could have helped me. One such example is the scaffold generator. I had always known this existed but I hadn’t been familiar enough with how this specific generator worked. As a result I was using multiple other generators, making files manually, and adding lines to existing files manually.
People have a tendency to avoid things they are not comfortable with. As a programmer, this is a self-destructive behaviour. Technology is constantly evolving because everyone is always looking for an easier way to do things. Since I started using Rails last year, it has gone from version 3.2 to version 4.1.8, fixing major security vulnerabilities and adding other useful generators.
After reading the documentation I am now much more confident in how Rails works, and have an even better idea of how powerful it is. I have actually already run into my next major hurdle… I know how powerful Rails is and what can be done, I just need to get good enough to DO IT. Reading the documentation is useful for learning methods and functions, but when it teaches you how to make gems or generators it only really shows you the basics, and those are some of the most powerful tools you can learn.
There seems to be a lack of intermediate Rails tutorials online, but that’s a different blog post. Maybe here at Monolith we will start putting out our own Rails tutorials for all you not-quite-beginners.
Alex Liedke, Developer
It’s such a simple question, and has such a simple answer, but how often is the answer actually good enough on it’s own (especially while programming)? I travel frequently, have family spread across North America, and friends living in other countries. For me “What time is it?” is a trick question that, on it’s own, is only accurate when talking to my friends in Ontario. This is a story about times when I genuinely do not know what time it is.
The real question you are asking is “How many hours difference is there between your schedule and mine?” I recently visited Europe for the first time, making stops in Brussels, Amsterdam, Berlin, France, and England. Even though those countries are all within 2 timezones, I suffered great confusion when in one city it was a 6 hour difference from Ontario, the next it was 5, and the one after that it was 4.
As it turns out, there are a WHOLE LOT of rules regarding time. For example the rule I ran into was that “not everywhere in the world switches daylight savings time simultaneously.” There are even some places in the world that don’t do daylight savings at all, or places that only SOME years observe daylight savings. There is even my favourite rule I’ve seen so far involving Shanghai losing 5 minutes and 52 seconds in 1927. Not to mention leap-years, other calendar systems, etc.
Here at Monolith we have run into some of these issues already. For example, commonly the time that the server registers is not necessarily the time here at the office, or even the time on the client’s computer. Not to mention switching to a different host could throw off whatever calculations you had in place already if you hadn’t done it dynamically.
As much fun as Europe was, between all the time changes, travel methods, and different beds it’s good to be home. Home where my body clock is still all over the place, but at least I always know what time it is.
Alex Liedke, Developer
There is a comet, called 67p / Churyumov-Gerasimenko (a catchy and memorable name to be sure, but we’re going to call it Klim the Comet), which has been circling our sun countless times for much, much longer than any of us can reasonably imagine. This poor hunk of rock and ice has been making its rounds every 6 years or so, just minding its own business for billions of years… Except for this time. This time was different.
This time a bunch of strangely-behaving carbon, oxygen, nitrogen, and other trace minerals got together. They dug up some metal, shaped it into something weird, exploded a giant pile of fuel and sent this hunk of metal and silicon hurtling 500 million kilometers and over 10 years through the dark emptiness of space just to shoot poor Klim the Comet in the face with a harpoon. Like some kind of space-age captain Ahab, armed only with a little maths, some chemistry, and the desire to spit in the face of creation itself.
The internet is abuzz with activity this week. Apparently someone took off their pants? And someone else put on a shirt? Or something? Normally this kind of active nonsense would send me off the deep end, ranting until I was blue in the face. But not this week. This week, we landed high-tech equipment on a freaking comet. We took pictures (and if you don’t look at those shame on you). And. best of all, we got to watch the whole thing live (well, 28 minutes delayed, but take it up with relativity). We’re drilling into this chunk of the universe to find out what it’s made of so we can understand it better. If that’s not some of the coolest things you’ve ever heard then I have nothing else to say to you.
For those of you still here, I’ll just wrap this up with a few quick words about why I’m writing this. I’ve always been fascinated by astronomy and space, but even if you’re not, there’s something undeniably cool about reaching out into the unknown and claiming a part of it on behalf of our species. This wasn’t just a project by the ESA, or some dude wearing a funny shirt, or even the EU… this was something humanity accomplished. And that is incredible. And inspirational. It makes you want to be great, doesn’t it?
Anton Baglaenko, Head of R&D
Newer blog posts
Older blog posts