In the following chapters, I teach you the tips and tricks I’ve learned over the years that will help you effectively follow the trends in our ever-evolving field. I also give you the techniques to help you select the best tools among a group of equivalent candidates. These techniques apply not only to Android libraries and tools, but to all ranges of tools used in IT in general. I use them every day whenever the need for a new tool arises. Finally, I present my Agile Android programming philosophy.
As an IT consultant, I’ve learned to stay on the cutting edge of innovation. I don’t do this for the money; I do this because I’m a technology junkie—I like to know what’s coming up, and I want to embrace the change instead of fear it. That state of mind opens up a lot of opportunities that the majority of our fellow developers won’t see, staying comfortably in their day-to-day routine. Instead, they follow trends only after they’ve become mainstream, and safer bets.
There are two groups of developers : the early adopters, and the followers. Personaly, I prefer to be an early adopter, and I also like to work with teams of early adopters. When I introduce new tools in a development team, the early adopters tend to be better ambassadors of change than the followers, which results in less resistance to change—independent of the scale of it. Change is like a stream that becomes a huge torrent when the snow melts in the spring—you can’t oppose it when it reaches a critical mass. The choice is then pretty simple : you ride the wave of change, or you risk being submerged by it; and becoming obsolete. Blackberry is a good example of a sinking boat—they once were the leader of the smartphone market, but they sat on their success and were submerged by their competition. What they didn’t seem to understand is that no company drives the market—customers do. Now Blackberry is struggling as is Microsoft because they were too late to jump on the smartphone train. On the other hand, Google and Apple have taken the early adopter approach, and that has paid well—a billion times over! Neither Google nor Apple invented the smartphone but they saw the opportunity; and embraced it.
Now, as a developer, you can also be on the cutting edge of technology by observing a wide technology watch of the entire IT market. But, how do you do this without spending too much time and energy?
Luckily for us, there are tools to help us, and—for the most part—they can be automated. So, you can spend only a couple of hours a week sweeping the market in search of a nasceant trend and digging deeper only when you see an interesting opportunity.
In this chapter, I start by presenting tools and techniques to observe the IT landscape as a whole, then I show you how to pinpoint your research to monitor interesting trends in more detail. Obviously—because of the subject of this book—I will show you how to observe Android trends specifically, but the techniques demonstrated here can be aplied to observe any technology you want.
One of my favorite tools is the TIOBE Index—it gives a good overview of where our industry is headed. The TIOBE Index is computed monthly using various data collected from major websites. Each month, TIOBE presents the results in a table ranked by popularity among more than 150 programming languages.
As of this writing, the C programming language (16.721%) is the king of the hill followed closely by Java (14.140%), and Objective-C (9.935%). It is no surprise that two of the three top languages for September 2014 are mobile programming languages—the mobile industry is still emerging, but the demand for mobile developers is high. I will leave it as an exercise to find out why the C language is the #1 language.
Another good way to take the pulse of our industry is to monitor the job sites—even if you’re not looking for a new job! It’s a great indicator of the demand for a particular technology. I recommend using a job aggregator for your monitoring because it saves you the trouble of registering at many job search websites, and it provides you with alerts delivered directly to your inbox.
I particularly like job aggregators like Indeed for its capacity to monitor the job market globally, by region, or even by metropolitan area. Always use simple queries to get the most possible results. For example, I have an alert for Android, which returns a lot of hits. You can quickly browse the aggregated jobs list to spot only the more interesting ones and determine the most commonly requested technologies for similar jobs. Be careful though, some technologies are hotter in the US than, let’s say, in Canada or Europe. For example, if you monitor Go programming language jobs, there is a big chance your search hits will be mostly located in the United States, and you will find fewer jobs elsewhere. That doesn’t mean Go is irrelevant and not worth monitoring. Go is a fantastic language that will continue to evolve, but it is still not very popular in Canadian or European corporations. That’s why it is important—while observing a technological watch—not to rule-out niche technologies; they may become the C language of tomorrow.
I recommend you register for the InfoQ Weekly newsletter, which is a newsletter that covers a variety of subjects related to software development. InfoQ also provides interviews, videos, books, and more. They organize a biyearly conference called QCon. I have followed the InfoQ website since 2006, and I have never run out of interesting news.
In the previous sections, I’ve shared some tips to help you stay informed about our entire industry—now let’s go into more detail and focus on Android specifically.
There are a lot of blogs, forums, news sites, and such about Android. If you read everything, you will be left with no time to develop great apps! Personally, I like to focus my search, so I am not overwhelmed by information.
One great way to achieve this is by using Google Alerts to target only one keyword for each alert. I recommend you have as many alerts as you have trends that you want to follow. It is pretty straightforward to create a new alert—visit Google Alerts: https://www.google.com/alerts. If you enter Android in the search field and then click the search button, you are presented with a preview of the most pertinent news—with millions of potential matches—that you will receive on a daily basis in your inbox. If you click on the More Options button, you can refine your alert by source, language, region, and result type. I recommend you leave all fields with their default values, except maybe the language field. That will be set by default according to your local settings (for example, mine are set automatically to French). You could select English or All languages, or you could create multiple alerts—one for each spoken language you want to monitor. It’s also important to keep the results type to Only best results. That will provide you with the more pertinent news and minimize the irrelevant news. When you are satisfied with the results, enter your email address and click the Create Alert button. You will then start to receive news from various sources—blogs, newsgroups, forums, news sites, and such—directly to your inbox without any further effort on your part.
Google Alerts will provide general news about Android. If you want to observe Android trends with a developer’s eye—to discover what technology to learn next, for example—Google Alerts is not enough. My number one source of information about Android development is the Android Weekly newsletter. I encourage you to subscribe to this free newsletter to receive fresh news about Android development on a weekly basis. It’s one of the major Android newsletters. They recently crossed the 15,000 subscribers mark—and most of these are Android developers.
Other good newsletters are Android Central, Android Authority, and Phandroid. However, most of the time you will find the same news in these newsletters that you find in your Google Alerts—unlike Android Weekly. You could register for these newsletters and—if one doesn’t provide you with enough interesting information—you can always unregister later.
One last source of information, albeit a little more noisy, is LinkedIn Groups. There are many groups related to mobile and Android, so I will not list them here. You can do a search on LinkedIn’s website. Focus on those with the most members because you’re more likely to find interesting discussions. Don’t forget to activate the Daily Digest option for each group so you receive the top news directly in your inbox.
I have one last piece of advice before moving on—don’t be tied to one source of information.
In this chapter, I’ve presented my tools of choice to help you stay informed about the market and its evolution. I like to use anything that can bring me information directly to my inbox, where I can use filters to order everything, and then read the news when I have the time. This may not be your cup of tea, and that’s okay. You can probably find the same information on various discussion forums, or even on some Facebook pages. Personally, I find that these other web mediums present too high a risk of distraction—oh, look at the cute little kitty!!!—and could ultimately move me away from my goal: staying informed without spending too much time scouring for the pertinent information through a pile of insignificant distractions.
There is one last source of information—routed through developer’s brains—that I would like to tap into using automated tools, but I can’t. That is the StackOverflow website. If we could access and aggregate the questions asked by millions of developers, order them, and data mine them, it would be a great source of insight on the market—perhaps even the greatest of all! I’m pretty sure we would get great insights from that pile of questions and answers. It’s on my wish list for Santa Claus.
Hint: check how the index is composed.
The C programming language was invented in the seventies by Dennis Ritchie, so how can it still be relevant today? Join the discussion on our Google Group, and share your theory on the following discussion thread : https://groups.google.com/forum/#!topic/agile-android-software-development/-WxI4PMP-Pg
As an Open Source software advocate, I prefer working with free software—as in freedom, and as in free beer—because I can lay eyes on the source code, and assess the source code quality, architecture, and even the seriousness of the developpers involved in the project just by doing a checkout of the project public repository. In comparison, you can’t look at the source code of most of the commercial software before deciding if you will buy it or not. There is some exception to that rule in the form of software developped using an hybrid model where a community edition is available as also a commercialy supported—and more feature complete—version; the IntelliJ IDE from JetBrains is a good example of that kind of product. Google engineers have tweeked IntelliJ Community Edition—the Open Source version—to produce Android Studio.
The Open Source community is composed of hundred of thousands—or even more—software projects. A couple of years ago, Sourceforge.net was the de-facto home for Open Source projects. Now, with the rising popularity of distributed version control systems (DVCS)—such as Git—GitHub has replaced SourceForce as the developers hosting provider of choice for Open Source projects. Open Source is now used by many organizations and is, in many case, critical for their daily operations. I will not dissert here why and when the perception of the corporate world about Open Source switched—from a perception that Open Source as hobby—to considering Open Source as a serious alternative to commercial software. Noneless, that shift in perception affect how we write software today, and it affects the Android developer community too: it is a fertile ground of high quality Open Source frameworks, and libraries. Luckily, that make it easy on our shoestring budget—if you happen to be a lone developer or part of a startup—but that brings another challenge, which is the topic of this chapter: How do you select the right tool among equivalent candidates?
I have putted an emphasis on right in the previous sentance for a reason: a tool could be right for you, but not for another developer. In this book, I’ve positionned many tools, which choice you could agree with or not. It all depends on your own software development flow and how these tools fit in. In the following sections, as an example, I will show you how I have selected the test driven development (TDD) framework we will use thoughout this book.
At the end of this chapter, you will be able to use those techniques to evaluate yourself Open Source software in term of quality, maturity, and so forth. You will be also able to reevaluate my choice of a TDD framework if it doesn’t suits you. Just by changing the required feature sets and the ponderation of those features the final result of the evaluation will not be the same.
Some choice of tools for this book were obvious and didn’t required much analysis on my part before selecting them for our Agile Android developer toolbox. A good example is Jenkins as our continuous integration (CI) server. While Jenkins won’t win any UI design contest, it has a huge and active community. Consequently, there are more plugins available for Jenkins—to extend its functionnalities—than all the other CI servers combined. For that kind of obvious choice—when not just going with the mass—I rely on popular annual reports to justify my gut feelings. In the Java world, there is two yearly reports I trust :
There are also reports from the research firms available—such as the Gartner Magic Quadrant—but they focus more on corporate tools and not solely on Open Source—these reports also happen to cost lots of money. Instead of buying one of those reports, I suggest you invest instead on cloud hosting, and a fast laptop—with lots of memory, and a large SSD. Most of the time, you should go with the mass and trust the Open Source project that leads the market—like Git for the DVCS. Not that the other tools are not good but because—when you need help—the probability to get answers from the Internet are better. You will end up spending less time searching for answers, and more writing code. But, when there is no obvious market leader, you have to do an assessment among equivalent tools to find out the best tool for the job.
In this section, I teach how to use a custom software assessment methodology to compare equivalent tools, and then make an informed decision. There is a couple of existing assessment methodologies, but most of them are now unsupported by their creators. For example, I was involved in the translation—English to French—of the Business Readiness Rating (BRR) methodology in 2005. The BRR initiative was ambitious in that it was—for the first time—proposing a formal, and repeatable method to assess Open Source software using a set of known metrics. It was a great improvment over some more hands-on evaluation methods such as Navica’s Open Source Maturity Model.1 But the BRR failed to get widely adopted and the OpenBRR website is now in a coming soon state for a long time. You can still find the RFC and the template spreadsheets used to compute the readiness rating, but not from the BRR website. Methodologies like BRR are great in case of medium to large corporations when you have to give justifications to upper management about your technological choices. For example, bureaucratic gymnastics are sometimes required when you want to set—or replace existing—corporate standard even in the case of a better, cheaper, and Open Source alternative is available. If you are interested to know more about the various Open Source software assessment, there is an article on Wikipedia about it.2
Some other people have pickup the BRR templates, and revisited them—the templates are available under an Open Source license after all. One mature initiative is the templates offered by Smals—a Belgian healthcare company—as Modèle de sélection OSS (French for Open Source Software Selection Model). You can download the templates, and the instructions freely from their website: https://www.smals.be/fr/content/mod%C3%A8le-de-s%C3%A9lection-oss. The download links are at the bottom of the webpage—even if the content is in French, the templates are in English. As you will see if you consult the templates, there is a lot of information to fill in before we can get any rating computed. That’s a great amount of work and research if you’re alone, and only want to make an informed decision about a new tool.
This is why I will present you in the next section with a custom assessment methodology which is less verbose—to the point—and more suitable for small teams.
How can we evaluate, and select unit testing tools for our Agile Android development toolbox? As we have seen before, the BRR–and the like–proposes formal processes to evaluate, compare, and select Open Source solutions by comparing the score of similar software. But, they are a bit overkill for small teams and one time evaluation. This is why I present you my own no-time-to-waste assessment methodology that focus only on selection creterion we really need to assess software development tools.
First, to help determine our feature requirements list, we will use Wikipedia’s article List of unit testing frameworks. Many langugages and plateforms are covered by that article but there is no specific section about Android. Fair enough, we will look at the C++ section to see if we can pick some features from there by observing the column names:
Those criterias can be used to evaluate any unit testing frameworks because they are generic and not tied to a specific programming language nor plateform. Those are also good example of discrete criterias–that is: they can be answered by “yes” or “no”–which is usefull to quickly rule-out any candidate that doesn’t match an must have feature.
Then comes the more empiric criterias–those can’t be answered by “yes” or “no”. Those creterias need to be converted to measurable metrics. To do so, we will define a scale–with values going from 0 to 5–that we will use as comparison factors. For example, if you define that an must have criteria to your unit testing framework of choice is to support Android, you could have this kind of scale:
Obviously, you will want to rule out any candidate that will score a 0 on the supported platforms scale. Other factors could be the following:
Feel free to add or remove some of that list as you see fit. As I mentionned before, this assessment goal is to help you to find the right tool. After all, you will have to leave with it–not your boss or project manager.
The score will then be applied with a pain factor ratio—how much will it hurt you in your job if you don’t have access to the said feature. If we use the precedent example, the pain factor ratio for the supported plateforms will have a ponderation of 1 on a scale of 0 to 1—or 0 for not required or 1 for must have. So, a multi-platform unit testing framework will score a 5 using the scale defined earlier.
Those weigthing factors are very subjective and–most of the time–couldn’t be re-used as-is for another evaluation intended to a different developer or a different team. What is a must-have for you might not be for someone else. For example, if your IDE of choice is Android Studio, you might have a criteria named Android Studio integration for evaluating your unit testing framework. You could then apply to this criteria a pain factor of 85% (or 0.85) because it is a must have but not something you couldn’t live without (or a pain factor of 1). Which will not be true for another team used to the command line interface (CLI) that will give a pain factor of 0 to the same criteria. You get my point.
So, we are done with the theory. We will now see how to select a unit testing framework that fits most of our need as an Agile Android developer.
The first step before we can even select our tool of choice for unit testing we have to found as many possible candidate as possible. Hopefuly, there is a couple of resources available to help us with that task.
The first one you should consider is The Android Arsenal website (https://android-arsenal.com/) which presents an up-to-date inventory of tools and libraries for Android software development. Tools are organized in categories and can be sorted using basic criterias such as registration date, last update, and rating)—which are not very helpfull with our assesment. You should use The Android Arsenal search fonctionnality to get a quick list of potential candidates, and nothing more. Unfortunatly, at this moment, there is no way to have access to a list of tags, which is what could be interesting for us. So, using the search tool, enter testing as search term and you will be presented with a list of potential candidates.
Keep in mind that you will have to revisit each candidate on that list to dig more details from the source code repository or the project’s homepage. The main reason for that is how The Android Arsenal organize information using tags. For example, some testing frameworks will show up when you use TDD search term but not when using testing keyword—even though they will fit in both categories.
Your second source of potential candidates should be GitHub—the defacto source code hosting service—for Android projects.
TODO
http://en.wikipedia.org/wiki/OpenSource_Maturity_Model↩
http://en.wikipedia.org/wiki/Open-source_software_assessment_methodologies↩
Reads:
115
Pages:
90
Published:
Sep 2023
I hope you enjoy this FREE ebook. Thanks for downloading it.
Formats: PDF, Epub, Kindle, TXT
Reads:
91
Pages:
74
Published:
Sep 2023
Databases are crucial for managing and utilising data effectively in various industries and applications. The aim of this book is to enable the reader to revi...
Formats: PDF, Epub, Kindle, TXT
Reads:
28
Pages:
293
Published:
Jul 2023
How-to's are step-by-step tutorials that are designed to help you learn more about Maya.
Formats: PDF, Epub, Kindle, TXT
Reads:
111
Pages:
176
Published:
Apr 2023
"No Filter, No Problem" by Famium is your ultimate guide to creating a visually stunning, engaging Instagram presence. Packed with insider secrets and practic...
Formats: PDF, Epub, Kindle, TXT