Questions? Call 855.338.8696

Titanium Dev…The Good, The Bad, and the Ugly [The Ugly]

Posted February 8th, 2012 by AR3
This is the sixth (and final) in a series of posts by DeveloperTown Associate Partner Andrew Robinson.

Start from the beginning with “We can create an app for that!”

We have reached the end of this blogging mini-series…but, don’t cry, because we will finally hear the Ugly truth about native mobile development, specifically with the Titanium platform.

The ugly truth is that delivering is the most important thing for the world that we at DeveloperTown thrive in. We cater to the agile-minded/lean-thinking starter community, which cherishes shipping quality product out of the door and iterating over the solution using real-world data and feedback from the people who matter most…yep, you guessed it…the actual Users. The productivity and speed to market gains you achieve when using Titanium make it a no brainer in most situations. There has been some ugly press about performance issues, or bugginess within the Titanium platform, but the bottom line is that Titanium greatly helps you ship a quality product, and it is getting better everyday.

So, we have taken the long way around, but we have finally landed on the Beautiful Truth that Titanium’s foundation in JavaScript, its clean and improving framework, and the excited community surrounding this platform, makes it a very good tool to use while building your art. Combine this with today’s power that comes with having your product/service available in an app store, and the wonderful dedication that our tribe has with shipping, it solidifies the reasons why you can consider building that new app as a native mobile app.

Regardless of what you choose to build with…please…don’t spend forever researching the pros and cons…see that fork in the road, make a decision, build it, and ship it out of the door!!!

Titanium Dev…The Good, The Bad, and the Ugly [The Bad]

Posted February 6th, 2012 by AR3
This is the fifth in a series of posts by DeveloperTown Associate Partner Andrew Robinson.

Start from the beginning with “We can create an app for that!”

No need for intros, lets get right to it…the bad parts of Titanium development.

Earlier in this series I hinted at the biggest bad there is for Titanium and any other abstraction platform…dependency. You are dependent on those guys out in Mountain View to stay as current as possible with the hardware platform upgrades. You are dependent on their quality assurance, and if they have bugs, you have to have workarounds. You are dependent on their existence…if they decide to give it up, you may be completely stuck, having to rewrite your app using the native platforms development environments anyway.

Appcelerator as a company has only been around for about 5 years on top of the native-native platforms being young as well; you are left with a fairly immature experience. I have run into inconsistencies, just plain inexplicable weirdness, and something’s that for all intents and purposes simply don’t work at times. There is a decent community that is excited about the platform, but Titanium is iterating so quickly it is hard to tell when the responses are stale. I semi-like the Stack Overflow-ish system they have put in place for the community, but again you get inconsistent results depending on what you are looking for.

Finally, there is debugging and optimizing your application. Debugging for the most part is a very good experience. It is only when you run into an issue that doesn’t seem to be caught by the debugger, when you are even aware of the veil that is covering what you are writing and the actual native platform underneath. When this happens you have to resort to incomprehensible logs from the device, or just trying different solutions until you get it working. It doesn’t happen often, but often enough to know that the platform is still in it’s growing pains period. As for optimization, I am referring mostly to memory optimization, which can seem to be a bit of a mystery. I am confident that the memory issues that you may read about from the early days of Titanium are being resolved and improved upon in every release. However, for very process intensive areas of your application, you may be tempted to dive into the native, especially if you are only targeting one of the stores/marketplaces.

If you are completely turned off by Titanium after reading this post, please re-read “The Good”, and wait on me to post “The Ugly”, where I try to summarize how I feel about the entire experience before you pass judgment.

Titanium Dev…The Good, The Bad, and the Ugly [The Good]

Posted February 3rd, 2012 by AR3
This is the fourth in a series of posts by DeveloperTown Associate Partner Andrew Robinson.

Start from the beginning with “We can create an app for that!”

So, we now know that one of the best canvases for your genius idea in this latest paradigm is mobile devices. We also have been over the native versus web dilemma. Last time we went over native versus native-native, and began talking about how abstraction platforms like Titanium can be useful in the delivery of quality solutions. Now we will dig into Titanium a bit. First, the good:

For me the most important thing about this particular abstraction is the language. If I were to do a series of posts about the “interactive web”, JavaScript would be King Kong of that discussion. JavaScript has had an interesting life from the perspective of application developers. It used to be an unwanted, glazed over, unfortunate necessity step-child that you threw in at the end of a project to make it appear a bit more interactive. However, now with the proliferation of AJAX-based applications and the general maturation of the web developer, it has risen to one of the most prominent positions in the app dev world. Given that many of the application developers that are at the forefront of the general tech movement are in the interactive web space, it makes JavaScript a sexy language to build your entire application with. JavaScript is not just for the UI anymore. You may have heard of rising star development platforms such as Node.js. Well, Node is not the only player in the server side JavaScript world, and I believe we are just at the beginning of the JavaScript movement.

The Titanium creators must believe, like me, that JavaScript is going to continue to play an increasingly important role in application development. I believe they have done a great job in allowing those JavaScript nuts to use their “hard won” skills as a foundation for productivity when creating native mobile apps.

Some of the Titanium competition (and even Appcelerator themselves in the early days of Titanium), make the claim that you can use all of your web dev skills when creating native apps. This is a decent MVP for creating an abstraction, but it is Not a good solution. Basically, it is putting a native wrapper around a browser. Not cool…not cool at all. Titanium has an entire framework that uses the JavaScript language, but has almost nothing else that translates directly from your current web dev skills. This is a good thing though… It reminds me of desktop app development, but with a new age web-esque event-driven OO twist.

I am also a fan of the eclipse IDE, which is what the Titanium IDE is built on top of. The framework is organized and well thought out. The documentation is pretty decent as well. Some stuff is android-y (like interacting with a hardware keyboard and menu buttons) and some stuff is Apple-y (like having a common top toolbar and swipe to delete gestures), and Titanium allows you to do both. You will lose some portability when you take advantage of platform-specific features, but it is a billion times easier than writing two completely different apps. Once you get the hang of where things are and how they interact with each other, creating quality solutions becomes very fluid and rewarding process. Overall, after you get over a few hiccups (which I’ll cover in the post about the bad) it is a pleasant and fast development experience.

Bottom line:

JavaScript goood…

Not utilizing a web browser wrapper and calling it native (if you want a web app, build a web app), gooood…

A very understandable and flexible framework that allows each platform to reach their potential…goooooooood…

Portability?! Portability?! You kidding me?! Don’t talk to me about mobile application development portability…

Posted February 1st, 2012 by AR3

This is the third in a series of posts by DeveloperTown Associate Partner Andrew Robinson.

Start from the beginning with “We can create an app for that!”

In the last post I left you with the native, versus native-native cliffhanger…I know, you couldn’t sleep in anticipation! Well, let’s get right to it…

I am a computer technologist/scientist, and I remember writing multiple reports throughout school about the great portability wars going on between Microsoft (with .Net backed by their CLR) and Sun (with Java backed by their JVM). The basis of this war was Microsoft said, “You can write in any of our languages, C#, F#, VB, etc, and they will all be converted into machine code by the CLR and run the same on any of our Windows-based machines”. Sun said, “You can write in Java and it will run on any platform that has a JVM built for it…which essentially converts the Java code into machine code”. In my opinion neither approach achieved true portability.

Portability in its purest sense is the ability to write once, and run anywhere, and this is even more important when talking about the array of platform options you have with mobile devices.

We have been discussing what the options are on our journey to deliver our innovative services to our potential customers. So lets say we want to go native…now we have to decide what platforms to target. The dominant markets include Apple’s AppStore and the Android Marketplace, so when building an app the last thing you want to do is build the same app multiple times on multiple platforms. Who cares though right…in the end we just want portability.

As with most attempts at portability, you usually start with a language/framework that you like, and have it compile down to the underlying platform’s language. In the mobile space there have been a few attempts at this, and the competition to be the “go-to abstraction” is heating up. We at DeveloperTown have done our research, and decided that the best option at the moment is a development environment called Titanium, built by Appcelerator.

Deciding to go with an abstraction like Titanium has its pros and cons. Biggest con is that with any abstraction you are at the mercy of the abstraction. To an extent, I’ll include the previously mentioned Sun -v- Microsoft battle. They basically put easier to use, more productive languages and frameworks on top of a compiler. Titanium does the same thing…it puts JavaScript on top of Java for Android, and Objective-C for iOS. Yes, you give up control, and put yourself at the mercy of the abstraction when you don’t use the native-native language/framework. But, the pros and cons of building on an abstraction in many instances outweigh the cons but, it is not all good…as we will see, there is some good, some bad, and some ugly…

To Mobile Web or to Mobile Native…that is the question…

Posted January 30th, 2012 by AR3

This is the second in a series of posts by DeveloperTown Associate Partner Andrew Robinson.

Start from the beginning with “We can create an app for that!”

On a journey with many forks, the only way to get to your destination is to make a choice and go.

The first fork is the question of “how do I get my product/service in the hands of the user”.  Should you focus on a website that is mobile-optimized/friendly/adjacent/amicable (there are varying degrees of mobile compatibility, and they go by even more names)? Or a native app…err, a suite of native apps, because of course there is iOS, Android, Windows mobile, Blackberry, or whatever platform your favorite eReader or tablet is built on. The issue is that each platform needs there own app built in their own language with their own framework and their own ‘isms’.

As with most in-depth multi-faceted issues, the answer is based on a specific situation. On top of that, this is a now versus then issue. If I were a betting man, and this was a long-term bet, I’d put it all on ‘native’ web. “Release early and often” is the mantra of many in the new era of business and especially application development, and mobile web is very conducive to this. The benefits of the distribution model when you are dealing with the web are fairly obvious. With the advent of the new power being built into HTML 5, CSS, and possibly a new JavaScript, the shortcomings of building true web applications when compared to native apps are being closed and closed quickly.

But alas, we simply aren’t there yet. Not to fret though, were we are, is an amazing place to be. If you have an app that needs/would benefit from interacting with the devices’ gyroscope, camera, GPS or notification system at the moment your only choice is to go native. Not to mention, the number one feature of any application is or should be…speed, and the bottom line is that currently native beats web every time in that department. Finally (and maybe most important to the apps success), there is the marketing, prestige, and customer trust/comfort that is associated with having an app in your favorite app store. Let’s be honest, if you go to a customer, and say to them, “yes, you can go to our website, but you can also download our app in the app store” you will get raised eyebrows. Having that edge could be the deciding factor in a conversion or another half interested prospect.

So, mobile web or mobile native…only you know the answer that is appropriate for you, but if your specific case does take you down the native mobile app path, there are yet even more forks in the road. I like to think about this next fork as native versus native-native… What’s the difference you ask…well, it all begins with portability, which we will discuss in the next part of this mini-series.

We can create an App for that!

Posted January 24th, 2012 by AR3

Technology flies by quickly. New paradigms crop up and just as quickly as they rise to domination, they are supplanted by the next great innovation. As application developers, we have gone from punch card apps to command line apps to desktop apps. Today however, there are two dominant platforms that have all but put the others out of their misery.

The first is the great connector…the Internet. With the emergence of incredibly responsive and powerful browsers such as Chrome and their movement to bring our entire computing experience to the web (see Chrome OS), the web is now, and will continue to be fertile ground for seeds of innovation.

The other platform isn’t as much a single platform as it is a powerful collection of platforms. With the average person creating and consuming their media, entertaining themselves, informing themselves, and connecting with others via mobile devices…the world wide mobile, is a force to be reckoned with. For evidence of this, just look down the street and count how many people are about to blindly walk into traffic, because they have their head buried in the little mini-world contained within their Android or i-device.

A few years ago, the bar for a business was to have a website. Then it evolved into having a web site with application-like qualities. Now, if I can’t completely interact with nearly all facets of your offering via my phone or tablet, I am incredibly put out, and will probably move to the next option.

So, we know that the new frontier is in the palm of the users hand, as creators it is our job to figure out how best to get our services, ideas, value add, innovation into the users hand. It is an impressive competition for the future going on, and I personally am excited to be able to see it unfold.

There are too many paths that we can take to handle in one post, so I am going to do a mini-series of posts about the world wide mobile…iOS, Opera, Android, Safari, Tablets, eReaders, Firefox ohh my!

One Startup Story: A Year of Deal Making

Posted January 20th, 2012 by John Wechsler

Robert Baer and Joel Curts started offering lunch deals at DailyLunchDeal.com in February of 2011. Their bootstrapped startup was lean and they both had full time jobs at (now, Indy’s most recent tech IPO) Angie’s List.

The first time I heard about their site I thought – “great, who needs another Groupon clone?” But as I got more familiar with their business — first as a customer, later as a fan and ultimately as venture coach helping them think through the myriad issues entrepreneurs face when launching a startup — I quickly came to appreciate their special sauce. Not only were “The Lunchmen” great salesmen, they had a laser focus on lunch deals combined with a tight geo target. This enabled them to focus their efforts on a couple of key metrics. Signing up restaurants. And signing up consumers. No strategery. No BS. Just start building the business. In fact, they signed up enough of both to attract the attention of a consolidator of daily deal businesses – Crusader Deals. And in true Lunchmen form, they acted decisively and closed the deal! Daily Lunch Deal is now part of Crusader Deals.

Working with Robert and Joel was a wonderful part of my 2011. Most of all, they are always upbeat and positive about things and impressed me the most their work ethic and knowledge of their customer base — two things any successful entrepreneur most possess.

Entrepreneurs can spend years looking for that special idea for a business. Many spend years operating and growing a business. Lots spend years trying to exit. These guys did it all in about a year! This is equal parts testament to their abilities as entrepreneurs and proof of their bankability as entrepreneurs in the future. Congrats guys! Now, what’s next?

Happy Birthday DeveloperTown!

Posted January 4th, 2012 by John Wechsler

INNOVATIVE VENTURE DEVELOPMENT FIRM CELEBRATES 2ND BIRTHDAY

“Lean startup” principles and proven, entrepreneurial success drive growth

Indianapolis, IN (January 4, 2012) – Innovative venture development and acceleration firm DeveloperTown turned two years old on January 1, 2012. To celebrate this milestone, the company took a look back at its accomplishments in 2011.

New Headquarters Facility

The year started off with the acquisition and redevelopment of the new DeveloperTown headquarters facility in emerging SoBro, a 35,000 square foot space on the Monon Trail at 53rd Street. Because the facility is home to other Central Indiana technology businesses like Tinderbox, Profyle Tracker, EX2 Partners, NPower Indiana and The Law Office of Brian Powers, it is rapidly becoming a networking hub.

The facility purchase and redevelopment was assisted by a two-year property tax abatement from The City of Indianapolis for occupying a formerly vacant building, a façade grant from Local Initiatives Support Corporation and Growing Economy (EDGE) performance-based tax credits from IEDC for planned increases in employment.

The Innovation Showcase

In July, DeveloperTown hosted The Innovation Showcase, the largest gathering of its kind to date where Central Indiana tech start-ups and investors got a chance to meet, network and pitch. Over 1,000 people attended the day-long event giving the 55 different companies that presented valuable exposure to the technology sector. This event was co-sponsored by Venture Club of Indiana, Inc. and Verge Indy.

Launch of uFlavor

After more than 10,000 hours of development, DeveloperTownʼs first project is ready to leave the nest. Coming on the heels of a successful national publicity tour, uFlavor (www.uflavor.com), the worldʼs first user-generated refreshment company, is setting out on itʼs own, with a team, a product and a plan to disrupt the multi-billion dollar beverage industry.

Launch of Musical DNA Education

For most of 2011, DeveloperTown worked on an online “game-ified” music education platform that was successfully released to the public at the end of the year. Musical DNA (www.musicaldna.com) uses a patented series of color-coded geometric shapes that fit together like pieces in a puzzle to teach people not just how to play music, but how to understand it. While still in its early stages, Musical DNA Education is poised to forever change the way the world learns to play music and DeveloperTown is thrilled to have made that possible.

24 Clients and Counting

When the company launched two years ago, the goal was to work with a range of clients – start-ups to mid-sized to Fortune 500 companies. 2011 proved successful, with DeveloperTown serving over two-dozen different businesses in a broad range of categories, positioning itself to further expand its size and scope in 2012 and beyond.

Thankfulness Exercises

Posted November 28th, 2011 by Bob Mattax

We were inspired by our friends over at SmallBox and thought we’d try on a little thankfulness as well.

Its easy to get caught up in the day-to-day and keep ourselves busy thinking about all the different tasks, and people that demand our time.  I think the holiday season presents an excellent opportunity ( though sometimes its hard to sieze ), to slow down, absorb some of the finer, ever-present details, and just bask in life.

Just making a list of things we’re thankful for wasn’t enough.  So, in an effort to be true to all of our inner-geek, I made a Venn diagram. ( If you are in a spot where you need to make a quick diagram, check out LucidChart ) I took some of the feedback I got from a handful of Devtownies, and tried to extrapolate the most likely things that all of us at DeveloperTown are thankful for.

DevTown Thankfulness

I’ve come to the conclusion that all of us here are thankful for our family, our friends, and our coworkers.  Sounds like we’re normal after all. :)

Original snippets:

Jason Vasquez – I’m most thankful this season for my family. I’m thankful for my coworkers who are more than coworkers, they are my friends; they are more than my friends they are my extended family. I’m thankful for our clients and the exciting technical and business challenges they bring that make it so much fun to continue to build DeveloperTown every day.

Matt DeLeon – I am thankful for the opportunity to start my career at an inspiring company in an up-and-coming city. But most of all, I am thankful for the incredible personalities of my co-workers.

Michael Kelly – I’m most thankful for the people in my life: my wife and one-year-old son, the great group of people I get to work with everyday, and clients who are passionate about their projects. But I’m also thankful that all the little stuff I take for granted each day… and that I have the luxury to do so.

Bob Mattax – I’m thankful for so many things.  I’m thankful for my loving family, and how much they contributed to making me who I am today.  I’m thankful for all my friends that feel like family.  I’m thankful for all my coworkers that not only feel like friends, but are.  I’m thankful for being able to be proud of who I work for, and what I work on.  I’m thankful for my dogs that brighten my mood almost every day. I’m thankful for my church that is filled with people who constantly love me like no collection of people I’ve ever met.  I’m thankful for good beer and great food.  And no joke, I’m so thankful for living in our wonderful country.  Along those lines, thanks to all the bold people, past and present that have stood up to evil and tyranny on behalf of the people.

Obviously, this diagram and these lists aren’t exhaustive.  I’d say we all could probably take more time thinking about all the things we could, and should, be grateful for.  So, the Thanksgiving holiday is over this year, but I say the spirit of Thanksgiving should go on, infiltrating the rest of our daily lives.

Go, and be thankful!

Risk, breadth, and depth of test coverage: can you see it?

Posted November 4th, 2011 by Rick Grey

DeveloperTown’s Rick Grey had a recent engagement managing regression testing for a web-based CRM solution. The scenario: the client was simultaneously upgrading to a new full version of browser, new full version of desktop OS, and new full version of a third application that was a mission-critical point of integration. Given the scope of the changes and the risk to the business (should the CRM solution turn out to have compatibility issues) there was an argument to be made for extensive regression and compatibility testing.

But.

For this project, instead of using a team of professional testers, the client enlisted users from the business to perform the testing. Part time, in addition to their usual duties. Over the course of just two weeks.

Yikes.

In a new article over at SearchSoftwareQuality, Rick describes the approach he used to both manage and communicate risk, breadth of coverage, and depth of coverage to the business users doing the testing and management stakeholders. The article, Beating the software testing time, budget crunch, includes a new method for visualizing risk, breadth, and depth of coverage that can be translated to projects beyond time-constrained regression testing. Check it out!

Archives

 

Categories