Software Development Methodology Cheat Sheet

Here is a quick software development methodology cheat sheet.

Note: There are many specific processes defined for some of the methodologies that are beyond the scope of this article. The main goal of this article is to give very high-level definitions of each methodology.

  • Waterfall - You do ALL of one phase, then ALL of the next, then ALL the next (eg. design -> coding -> testing).

  • Agile - Agile is a philosophy, not a step-by-step methodology1. It is a set of attitudes about software development with the goal of improving communication and the overall development process for all parties involved. You are "agile" if you align yourself with the agile philosophy and make your actions in development reflective of that.

  • Scrum - A template of steps to follow for the development cycle. It is an implementation of agile- it is supposed to follow the principles and attitudes of the agile philosophy. At the same time, it actually gives you the steps that you can follow. In this methodology, you have a prioritized todo list, and you incrementally and iteratively complete chunks of the todo list. By performing incremental and iterative development, you allow requirements to be flexible and changeable since you are not commiting to completing one entire phase before moving to another one (waterfall). Thus, the development process can better cope with inevitable changes.

  • Extreme Programming (XP) - XP is a methodology which implements a set of rules that you follow to optimize software development and make it easier to collaborate and work with a team while sustaining a high level of software quality. XP is an agile methodology as it aligns with agile principles.

  • Kanban - A software development process that aims to manage the flow of items being worked on (for example, the flow of completion of each item on the project's todo list). Kanban processes seek to identify and eliminate bottlenecks in the software development lifecycle.

  • Lean - Product development principles that have been translated to the software development domain from lean manufacturing. There are 7 principles- eliminate waste, build in quality, create knowledge, defer commitment, deliver quickly, respect people, and optimize the whole.

  • Cowboy Coding - Developers have complete control of software development. There is no formal structure that guides the project along. The easiest way to think of this is as a "free for all" where you can do whatever part of the project you want whenever you want.

  • Iterative Development - The software is built knowing that future versions (iterations) will be used to refine the project.

  • Incremental Development - A software project is divided into chunks and each chunk is developed by the team, one at a time.

  • No Silver Bullet - A paper written in 1986 by Fred Brooks, in which he argues that "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity."

Let me know if I've missed anything and I'll put it up!

  1. In the real world, a lot of people mix up agile and scrum. Sometimes they mix up agile and some other completely unrelated methodology. Just remember that agile is the philosophy, scrum is a methodology, and people will probably get them mixed up. 

How To Teach Yourself To Code and Program

So you've decided you want to be a developer. You want to understand code and be a master of computers. You want to tell them what to do instead of struggling to figure out what they may or may not be doing. But you don't know where to begin.

I'll help you out.

Pick a Language...any language

First, pick a language. Any language, ideally one that interests you. But if you don't know which language would interest you, just pick anyone.

  • Python
  • Ruby
  • Java
  • C#
  • PHP
  • C
  • C++
  • Etc. etc. etc.

PHP, Python and Ruby are languages typically used to power dynamic web sites. Java and C# are powerful languages that are used to power web sites that are heavy on traffic and are often used in game development and in many other applications. C is the mother of all languages and is the source for a lot of linux packages.

There are A LOT of languages. Pick one and learn it's syntax. A lot of what you learn in your language of choice is transferrable (you won't have to learn your second or third language "from scratch").

Learn How To Write And Execute Code In That Language

The best way to learn syntax is by writing programs yourself. This means defining a problem you want to solve and writing a program that solves it. However, everyone has to start from scratch, and if you don't know ANY syntax, you have to start somewhere. Learn the basic core concepts of the language of your choice:

  • How to write code by following syntax rules
  • How to run the written code

Different languages have different syntax rules (how to write code properly so that the computer can understand it), different data types (eg. number data, letter data and word data), and different tools to help you create or manipulate that data. There are lots of free books and resources online that will teach you. In fact, here's a whole list of them. Awesome!

There are also lots of great Youtube Channels that have full courses on how to program. I love thenewboston. This was the channel that helped me get my feet wet with mobile application development when I began learning how to program. You can also search YouTube for "[language name here] tutorial" and look for programming tutorials. Before you know it, you'll be writing all kinds of programs!

Different languages are executed differently. PHP is interpretted, while C is compiled and then the resulting binary can be executed. Java uses the Java Virtual Machine (JVM) and C# uses the Common Language Runtime (CLR) to ensure compiled code can run on almost any machine. It's okay if you don't know what any of this means for now. But learn how the language you are choosing is executed- how the computer knows to run the code.

Start Writing Programs

Once you have a basic grasp of the syntax as well as how the language is executed, start writing programs. Here is a key lesson that may not be obvious.

It is okay to research when you write your programs.

It is okay to google. Developers google a LOT. Googling saves time. Googling cuts cost, effort and increases efficiency. And there are lots of things you will not know on your own without googling.

You will almost never write non-trivial programs off the top of your head without consulting external resources.

There are many situations in software development where you will not be able to derive a solution on your own. You will need to use an external resource to solve a problem. For example, you would not be able to intuitively deduce how to make an app work on Android, even if you perfectly knew the syntax of the language Android apps use (Java).

That previous link is to a page of the Android developer documentation. The documentation contains a complete listing of methods and functionality you can use when you write apps for Android. This functionality is collectively known as an Application Programming Interface (API).

There is no way you can know what the API allows, what functions or methods you can use, without doing research. This is a common theme in programming. You need to research. Get good at researching. Get good at understanding your research. And based on what you learn, you can come up with a solution for the problem you are trying to solve.

While we're at it, here is another key lesson.

Documentation is a developer's best friend.

Developers are constantly writing code and consulting external resources, especially API documentation.

If you check out the Android API, you'll see it's HUGE. How is a developer supposed to learn all of that?

Languages and APIs typically have A LOT of tools and functionality. You will not be able to learn them all without devoting a ton of time, and this will be a wasted effort. APIs frequently change. Functions and methods get deprecated, new ones get introduced, bugs are found and fixed, exploits are discovered and patched, software rots. And thus, APIs are constantly changing, evolving and even growing. This is the nature of the beast.

Here's how to make sure you don't waste your time.

The trick to efficient programming is to learn what you need when you need it.

You don't have to know every single function or method a language library offers. Just focus on learning and understanding what you need in order to solve your problem. As you write more programs and solve more problems, you'll begin to see what is commonly used, what is not, and how to learn to do what you need to do should you ever be confronted with a new problem you've never solved before.


So to conclude, a quick recap. In order to start learning how to develop, you must:

  1. Pick a language
  2. Learn how to write and execute code in that language
  3. Start writing programs!

And it's okay to use external resources! In fact, you should get good at researching and understanding what you find.

That's it for now!

Android: Robolectric Unit Testing a Local Disk-Based SQLite Database

Documentation was sparse regarding how to run Robolectric unit tests on a local database file stored on your computer. So here is what I managed to find.

The Problem

Robolectric is a great framework for running Android unit tests without having to deploy the application to your device or to an emulator. As a result, this significantly speeds up unit testing during Android application development.

However, SQLite databases become tricky when you have a premade database on which you wish to operate and invoke tests. This is because Roboletric uses an "in-memory" database for all SQLite operations. This works great, if you are running database creation queries and building your tables directly within the testing environment. Otherwise, you may find yourself looking for a way to test on a premade database.

Don't worry. If you want to use a pre-made database and run your tests on that SQLite file, Robolectric's got your back.

The Solution

First, ensure that the Robolectric dependency in your pom.xml file is version 2.1 or later. Support for local disk-based SQLite testing was introduced in version 2.1.


Once you have that done, place a copy of your database file in the ${project_root}/src/test/resources directory.

When you compile your tests, files in this directory will get copied into an "output directory" containing all the compiled classes and files. On my machine, the directory is located at ${project_root}/target/test-classes. Thus, the file you place in the ${project_root}/src/test/resources directory will not be modified in any way. The copied file in the "output directory" will be modified. Any database operations performed in your unit tests will be operating on that "output directory" database file.

Now create a new Java test file. We'll call ours

public class DaoTest {

  // This path is relative to ${project_root}/src/test/resources
  // This path is used in building the absolute path for the database
  private static final string DB_PATH = "/database/MyDbFile.db";
  // This will contain the absolute file path to the database
  private string dbPath;

  public void setUp() throws Exception {
    String path = getClass.getResource(DB_PATH).toURI().getPath();
    File dbFile = new File(path);
    dbPath = dbFile.getAbsolutePath();

    // Perform any other necessary set-up operations...

  public void tearDown() throws Exception {
    // Perform any necessary clean-up operations...

  public void testGet() throws Excpetion {
    SQLiteDatabase db =, null, OPEN_READWRITE);

    // Perform database operations...

    // Perform assertions on query results...


That's it. It really is that simple!

dbPath will contain the absolute path to the database file in that "output directory." From there, you can invoke SQLiteDatabase.openDatabase() and perform any necessary operations on the disk-based SQLite database file.

The Application Development Workflow: Brainstorming


Everything begins with an idea.

However, the dirty little secret of most (if not all) ideas is that ideas are worthless on their own. Ideas are absolutely not valuable on their own. They are a starting point and nothing more. I say this because you might end up finding the same thing I did- you may come up with several ideas that you think are novel that have not yet been implemented. Yet no matter how new the idea may seem, during market research, you will see that someone has tried to create your idea before in some way. If you are not prepared for this, it can be seriously demotivating. Ideas are the starting point. But there is a lot more work that comes after. This document focuses on how to develop ideas in preparation for all that work that will come after.

List your ideas

Have a LOT of ideas. Brainstorm until you are blue in the face. Have good ideas, have bad ideas, get it all out of your system. Build a long list of ideas for applications to develop. When you are comfortable with your list, you can begin sorting through each idea.

Place each idea in one of three groups - Not Developing, Maybe Developing, and Developing.

  • Not Developing - This group will contain all ideas you will not pursue developing and that you do not see yourself developing anytime in the future.

  • Maybe Developing - This group will contain all ideas that you may want to pursue developing in the future.

  • Developing - This group will contain all ideas that you may want to pursue developing immediately.

How you sort through your list depends on your motivations for developing an application. Are you looking to make money? Sort based on what may bring in the most revenue. Are you developing for fun? Sort based on what most interests you. Are you looking to build a portfolio? Sort based on what would be most persuasive to potential employers looking for new hires in the field you are pursuing.

Ultimately, your goal should be to have five ideas in the "Developing" Group. The rest should go in either the "Not Developing" group or the "Maybe Developing" group.

Define Your Goals

Once you have created a solid list of ideas, you must define the goal for each idea listed under the "Developing" category. Each idea can have its own separate goal, independent of the others. Defining these goals will help you further narrow down which ideas you are willing to commit to.

The goal can be whatever you want. Some examples include the following- to learn how to develop for the platforms of your choice, to build a portfolio, to try and build a financial revenue stream, to expand a business etc.

Note: One word of caution- financial revenue is NEVER a guaranteed outcome. Like any other business, a for-profit venture does contain its risks. In addition, you must be aware of your tax laws in case you do end up building a product that brings in revenue- in this case, you will have literally created a business.

Perform Market Research

Why perform market research

The goal of market research is twofold - you must understand the competitive environment of the market you are entering and you must learn what potential users are expecting of your application. This is important for any project, including open-source software. The lifeblood of any application, and of all software in general, is its users. If you are not competing for price and value in the commercial sense, then you will almost certainly be competing for a users time. In either case, it becomes clear that you will have competition in some way. Do not neglect proper research simply because you may not have financial motives.

Market research unlocks a treasure-trove of information that will be very helpful in developing an application that matches and even exceeds user expectations as well as information regarding the market ecosystem and how your application may fit in it, depending on the developmental choices you will make. This information includes things like- expected features and functionality, how to reach more users, how to retain users, how to stay relevant, and what users are willing to pay for. With this knowledge, you can build an application that users will enjoy, and find ways to differentiate your product.

Your market research process may evolve as you discover the most effective means of research for your particular market. But a boilerplate sample plan can certainly help if you have no previous experience with this kind of research.

How to perform market research

Market research is one of the components in the application development process where you will be straying into another field. Large companies have teams dedicated to marketing, market research, etc. Here, you will do your best as you go along, constantly learning. You may not have a large team, but there is a lot of useful data that you can find and analyze on your own.

For each of the applications in your "Developing" list, gather the following information using whatever resources are available to you (search engines, Google Play App Store, iTunes App Store, etc.; also, be sure to save your research in a txt or doc file for future reference):

  1. Identify your target market and your target users - parents, teens, mid-twenty-year-olds, gamers, musicians, book-lovers, calligraphy enthusiasts, etc. The more specifically and clearly you define your target market, the more effective your actual marketing will be. You don't have to limit yourself to one market category per application. However, "targeting everyone" is not going to be very helpful.

    • Speak with people who may fall under your target market. People who are interested in similar applications. Ask them what they like and what they dislike about the similar applications. If you can get this info directly from potential users, you will be off to a great start. This kind of information is valuable.
    • Your target market are those who you must persuade to download the application. Your target users are those who will actually use the application. Usually, both are the same, however there are cases where they are different. If they are different for your case, be sure to identify the category under which your target market falls and the category under which your target users fall. One very common example are "children's apps" whose target market are parents and their target users are the children.
  2. Identify your competition - Identify at least 5 applications that are similar to your idea that currently dominate the marketplace. Take notice of the general number of similar applications that exist and write that number down. Then, gather the following data for each of the applications you have chosen to analyze.

    • Application URLs - The app store URL for the product and their website url, if they have one.
    • Application Description
    • Application Category - The store category that the application is listed under.
    • Application Maintenance - The current release version as well as the date of the last update.
    • Application Size - The amount of storage space the application requires.
    • Target Market - Who is being persuaded to download the application?
    • Target Users - Who is actually using the application. Often, this is the same as the Target Market, but not always.
    • Hook - What is the applications main "selling point"? Is there something about it that makes potential users curious and persuades them to check it out and click download? It can be gimmicky and it does not have to be very useful. However, it will convince potential users to download the application. Not all applications have one and not all application developers know they have added one.
    • Pros - The good stuff the application offers. Download the application, use it and make your own observations. Then, read the user ratings and take note of what others liked about it.
    • Cons - The bad stuff that hurts the overall application. Again, download the application and make your own observations. Then, refer to the customer ratings and take note of what others did not like about it.
    • Screenshots - How many screenshots are being displayed? Are they tablet screenshots? Are they mobile screenshots? What parts of the application are being displayed?
    • Videos - Take notes on how they use video to market their product.
    • Store Listing Design - Observe the app store page design, specifically how the product is being marketed in the context of the overall page. Look for tailored styles, custom images, anything that is not a part of the default app store. Take note of anything you find. You may have to decide whether or not you wish to spend time designing your own assets (e.g., a banner "feature graphic" for the Google Play store). You also want to take note on how they use these styles, images and other assets to market their product.
  3. Identify your product's hook - You should have at least one major differentiator for your own application. You have knowledge on what is already out there in the market. Now how will your product be different? It doesn't have to be anything special or revolutionary, but it can be. It could also be some gimmicky feature that would capture interest and persuade potential users to download the application. The overarching point here is that you will almost always have competition, and lots of it. Giving yourself a hook, a differentiator, is a good attempt at getting some share of the market for your product. It is certainly not a guarantee, but depending on the hook, it can increase your chances in successfully building a user-base.

  4. (Optional) Identify potential revenue channels - For each of the ideas in your "Developing" list, determine whether or not you wish for it to be a for-profit commercial product. If so, identify potential revenue channels.

    • Advertisements - This can bring in some revenue if you end up having a LOT of users. However, ads are not appropriate for all applications. For example, you may decide that placing ads in applications that target toddlers (by marketing to parents as a "children's application") is not a very good idea. Decide whether or not your application is a suitable candidate for ads and whether or not you want to implement them.
    • In-App Purchases - These days, In-App purchases are definitely something to consider if you are seeking to bring in revenue. Avoid compromising the experience of the application in anyway that makes it unfair to the free users. For example, a game where the paying players always win may immediately lose value; the free players (who are potential customers) may simply stop using the application, and consequently, you may end up with a smaller and smaller pool of paying customers.
    • Premium Version - You may consider making a paid premium version of your application. This version would offer more features that enhance the application experience while still allowing non-paying users to have access to the free version. I would consider making this an In-App purchase as opposed to a separate application. That way, the upgrade more accessible and will allow for users to upgrade at their leisure.
    • Other - You can get creative and find other ways to monetize your application. The previous suggestions tend to be the standard methods of bringing in revenue. But if you know of another method or if you can create your own, and if it follows the terms and conditions of the platforms you plan to support, then go for it and give it a shot!
  5. (Optional) Identify localizations you wish to support - The more languages your application supports, the wider the net you will be able to cast for building a user-base. All mobile application platforms offer localization support for text and images. So plan ahead of time whether or not you intend to support other languages. If you speak other languages, consider providing support for those languages. Be sure to take into consideration whether or not a market exists in the languages for which your are considering providing support.

Make Your Decision

After having completely racked your brains for application ideas, filtering down that list, and thoroughly researching the market, you now have enough information to decide whether or not you really wish to pursue any of the projects in your "Developing" list. Eliminate those that no longer interest you. Then simply decide here and now whether or not you are truly willing to commit to completing the ones that remain.

I would, at maximum, work on two or three personal projects at a time. The more projects you take on at one time, the longer they will take for you to complete.

If you have decided you do not want to pursue any of the ideas on your "Developing" list, you can do one of two things. You can refer to your "Maybe Developing" list and reconsider some of those ideas. Or you can start again from the beginning and come up with a whole new list of ideas.


The entire Brainstorming Phase may take days or it may take a few weeks. Do not get discouraged if you find yourself spending a week or more on it. Remember, you will probably spend months working on the project itself. You do not want to end up starting work on something on a whim, only to find out later that you are no longer interested in the project, or that it may not be profitable, or any other line of reasoning that could have been prevented with proper planning and research.

There is a lot of information here. Use it as a baseline and tailor it to your particular goals. The ultimate point is that you want to have well-researched data and make well-reasoned assessments that will help you understand the scope of the project you are taking on and its potential requirements for completion. Hold on to all the information you have gathered so far. It is going to be organized in the next phase as part of your project documentation.

The Super Quick Guide to Mobile Application Development


Developing an entire application takes approximately 2-3 months of full time work, if you are working on the entire project by yourself. This can easily increase with the complexity of the application. As you will soon see, it takes such a long time because there are many aspects to application development - testing, design, and lots more. Writing code is only a portion of the entire process.

The following is a quick overview of the entire mobile application development process. While different projects will almost certainly have different requirements and different workflow-bottlenecks, this document should give you a very high-level understanding of what it takes to build a mobile application.

Mobile App Development Outline

The high-level overview of the app development process is pretty simple. It can be broken down to six phases:

  • Phase 1 - Brainstorming
  • Phase 2 - Wireframing
  • Phase 3 - Design
  • Phase 4 - Development
  • Phase 5 - Testing
  • Phase 6 - Release

Ideally, there would be a team, and each member could focus on their specialties. However, if you hope to master becoming a solo developer, you should take each phase seriously.

In other words, do not neglect one area simply because you feel you may not be good at it. There are plenty of resources that will teach you the fundamentals of development, design, testing, iterative release cycle practices, etc. It will be a lot of work, but it is possible.

Phase 1 - Brainstorming

With the knowledge that building a fully functional application can take anywhere between 2-3 months of full-time work (and longer if you are only developing on a part-time basis), it very quickly becomes clear that app development will be a huge undertaking and a big investment.

Therefore, it is crucial that you plan your project as thoroughly as possible. As the project progresses, you will end up making changes, coming up with new ideas and new solutions for different parts of the project. However, you need a solid, well-built plan that will act as the foundation for the rest of your project.

Brainstorming includes (and is not limited to) the following:

  • All ideas you have of potential projects you may or may not pursue
  • Your goals and the reasons you are undertaking the project(s)
  • Market research of the projects you wish to pursue
  • Your application specifications - detailed criteria for the application you intend to develop
  • Knowledge of the resources you will need to complete and deliver your application

Phase 2 - Wireframing

Wireframing begins once you have a solid well thought-out foundation underlying your project. Wireframing builds on all the work you have done during the brainstorming phase. Wireframing helps you begin building something tangible.

Wireframing forces you to thoroughly think through the entire application flow at a high level. If you wait too long and make wireframing decisions during development, you may find yourself with a badly designed application. This is because development focuses on the much lower-level aspects of the application, the individual building blocks as opposed to the overall blueprint. These are two very different perspectives and they each deserve individual thought and consideration. The high-level (wireframing) focuses on the overall structure and functionality of the application and the low-level (development) focuses on how that structure and functionality is actually implemented- how it works at the code level.

You can wireframe on paper or you can use software. In either case, what you want to do is create a preliminary model of your entire application. From the launch screen, to every other screen, you want to begin conceptualizing the entire flow, structure and basic functionality of the application. You want to build the skeleton of your project based on what individual components do more than anything else. This is not the time for designing graphics. Focus on functionality and keep it bare-bones simple with regards to presentation.

Phase 3 - Design

The design phase takes approximately the same amount of time as the development phase. It is possible to handle development and design yourself. However, the main issue with such an approach is efficiency. You can get a lot more done in a lot less time with a well-organized and well-coordinated team than you can by yourself. But in the case where this is not yet possible, it may be that you have to take on the design role yourself.

Be aware that you should be putting as much effort into design as you are going to put for development. This means learning a little bit about color theory, typography, vector art, icon design and more if you do not have any previous experience.

Design is important. No matter how well-written your code may be, your users may never see it. Well-written code should never be noticed. Badly-written code will be noticed, because the functionality of the application will be hindered in some way (e.g., through lag, crashes, etc.). Design, however, is the phase that allows you to present your application in any way you wish to the user. You can make it look professional, competent and visually appealing, or you can make it look the opposite.

To start off, learn the techniques you need for the project at hand. If you need some image buttons, this is an opportunity to learn about iconography and all the necessary skills successful icon and button design may require. Learn what you need. Inevitably, you will end up learning skills that you will be able to apply elsewhere in the future.

Phase 4 - Development

You have an idea, you have done your research, and you have thoroughly wireframed your application! You have even completed most, if not all, of the necessary image assets and other design resources. Now you can finally get to the coding aspect of the project.

This will take some time and a lot of problem solving. You will handle the platform-specific APIs to interact with the mobile operating system and make your application do exactly what you want it to do.

There's not much else to say. You code, you run the application, you debug and then you code some more. It will be a slow process. Some days, you may only successfully implement one feature. Sometimes, it may even take days of full-time work to implement one feature. This is one of the critical places the brainstorming phase will help you- you will have defined a set of application specs required for the first release cycle. So while feature creep1 may be tempting, your set of requirements will trump anything else, keep you on task, and keep you on schedule. If you find yourself spending too much time on components not part of the original set of specs, it may be wise to cut that component out entirely.

Manage your expectations and focus on your core requirements. More often than not, those few core features alone will take a long time to properly implement on various platforms as well as (depending on the platform) numerous devices. You can always expand in future release cycles.

Phase 5 - Testing

The testing phase is the phase in which you rigorously put your application through as much trouble as possible. The goal is to build a high enough confidence that your application will work under any number of conditions and under any sort of treatment. The testing phase is the phase that your application is being prepared for the production environment. You are preparing to publicize.

You need to test on as many devices as you can get a hold of. If you have access to physical devices, use them. Emulators and simulators are also available for the different platforms. You can use them to run the applications on your computer. However, testing on physical devices is always the best option. You will not know how various parts of your application are functioning in a real world setting unless you get it running on a physical device.

Always run your tests on both the oldest device you wish to support as well as the newest device you wish to support. Test on the different screen sizes you wish to support. Test on tablets as well as phones if you are providing support for both. The end result should be that you are testing on a sample of devices that is representative of the total number of devices you wish to support. You may not be able to test on all of them, and in some cases, testing on every device will prove to be impossible (e.g., Android runs on thousands of different devices). Build a manageable sample of devices you can test on, use emulators and simulators, and make sure to test on physical devices.

You may also consider performing alpha and beta testing. These are actually a critical part of application development as well as software development in general and there are many different ways to approach and execute these kinds of tests. This should come after your individual sample-testing. The goal is to try and put your application in real-world conditions using a much larger sample size than you can provide on your own.

Testing is a major phase of software development. But it ensures that your application is or will become reliable, robust and functional for all users.

Phase 6 - Release

The release phase is more of a pseudo-phase. While it may not take as long to complete as any of the other five phases, it will not exactly be a one-click-submit-and-you-are-done kind of deal. There are several things you need to prepare for and several things you need to do for the release phase.

In some ways, release is a lot like building a website landing page for a product- you're going to need to show off your product, consider the best SEO and keywords to use, write an attractive description and more. All of these will be used by the various app stores when you create your application listing. This is a major part of the marketing involved so that potential users will want to download your application.

There are also technical requirements that you will have to complete, such as signing your application using a digital signature to tie the application to your identity. This signature would be used to allow future updates from only that signature.

The different app stores give you all kinds of tools for monitoring your application as well as various metrics- crash logs, download rates, retention rates and more. Monitor and use this information for future release cycles.


Application development takes time. As you progress, you will learn and become more and more efficient. Soon enough, you will have completed your entire project. Like with anything else, all you have to do is keep at it.

  1. Feature creep - Over a long time period, extra unnecessary features seem to "creep" into the codebase. These features usually go beyond the application's goals. This is often seen as negative because it typically introduces more complexity to the code while providing little to no value. At its worst, it can severely delay project completion and has been known to kill entire projects. 

Markdown Syntax Cheat Sheet

Different video tests

Here is a quick markdown reference. Everything described here holds true for hackBytes and most markdown-processors unless otherwise stated.

Literal characters

Escape with backslash.

\*       ==      *
\*\*     ==      **
\#       ==      #
\#\#     ==      ##
\\       ==      \




h1 can be done with 1 or more equal signs on the line below

h2 can be done with 1 or more dashes on the line below

Emphasis (bold and italic)

For bold AND italic, you can use what is displayed here or combine * and _.

_underlined text_
*italic text*
**bold text**
***bold and italic***


Titles are optional for all formats.

[anchor text goes here]( "Title"

You can also link using references/footnote-style links. The first set of square brackets defines the anchor text. The second set of square brackets defines the reference id. You can define the link anywhere in the document.

This is the [anchor text][id] for a link.

Now I'll just define the link at the bottom.

[id]:  "Title"

Paragraphs and Line Breaks


Single newlines are ignored. Two or more newlines make a new paragraph.

This line is example 1. It is its own paragraph.

This line is example 2. It is its own paragraph.

This set of lines is example 3. The single newlines used in this example
will be ignored. The entire text in this example is treated as if it
were a single paragraph.

Line Breaks

This one is a little tricky to describe, but it is really easy to use.

Line breaks are newlines rendered as <br> instead of as <p> tags. With the paragraph rules alone, there would be no way to render <br> tags. However, markdown does let you render them.

Simply add two spaces at the end of the lines you wish to break. Otherwise, markdown will treat the set of lines as a single paragraph, as mentioned earlier.

The following example would not result in a single paragraph. Instead, markdown would render two lines separated by a <br> tag.

This is line 1 for a line break example. This line contains two spaces at the end.  
This is line 2 for a line break example. Without the two spaces on the previous line, these two lines would be treated as a single paragraph and would contain no break.

Horizontal Rules <hr>

Use three or more dashes, underscores or asterisks on a single line.

Sample text with hr underneath. Two newlines required here, as single newline conlicts with h2 header rule.


Or like this. A single newline is required, but two will work as well.


Or even this. A single newline is required, but two will work as well.


Wrap code with three backticks to render code tags for syntax highlighting.

def syntax_highlight() {
  puts "Hi!"


> Add blockquotes to your pages
> using the greater-than angle bracket
> for each line you want to be part of the quote.

> > Nest quotes with multiple angle brackets.

> You can use any of the other markdown styles within blockquotes.


Use pipes | to define tables.

The actual text does not have to line up to look like a nice table. Whitespacing doesn't really matter (except for newlines).

| Table header 1 | Table Header 2 |
| row1 - column1 | row1 - column2 |
| row2 - column1 | row2 - column2 |

Outer pipes are optional:

 Table header 1 | Table Header 2
 row1 - column1 | row1 - column2 
 row2 - column1 | row2 - column2 

You can also define column alignment via the table-header and
table-body separator:

|:---| - left-align
|---:| - right-align
|:--:| - centered
|----| - default (no defined alignment in the rendered html).


Numbered Lists

1. List item 1
2. List item 2
3. List item 3

Bulleted Lists

* List item 1
* List item 2
* List item 3

- List item 1
- List item 2
- List item 3

+ List item 1
+ List item 2
+ List item 3

Nested Lists

You can nest lists like this.

1. Level 1
1.1. Level 2

* Level 1
** Level 2

1. Level 1
** Level 2

Or with tabs

1. Level 1
  * Level 2


Type in some raw HTML...

<div class="test">
  Just like this!


Images are a lot like markdown links prefixed an exclamation mark.

![alt-text](/img-path.jpg "Optional title")

Videos (hackBytes-specific)

This is simply a convenience tag for hackBytes and is not part of markdown. It will not work anywhere else unless it is manually implemented.

[video url-here]
[video url-here | style-here]

About hackBytes

Who is hackBytes for?

hackBytes is written for anyone who wants to master programming, as well as computer science. The current focus for all content is mobile and web application development.

What is hackBytes?

hackBytes is, at it's core, a set of notebooks. It contains a distilled, to-the-point version of all the notes I have taken and the lessons I have learned as a growing mobile and web application developer. The one caveat is that I am intentionally making sure that the entire website can be understood by anyone. That way, hackBytes can be used and understood by anyone seeking to learn and improve their programming skills.

If there are ever any prerequisites to being able to understand something, I will either:

  • teach them myself
  • point to the most efficient way of learning the material

I do not intend to treat hackBytes as if it were a blog. Technology evolves and concepts change all the time. As a result, I may decide to update old articles with new information. If it helps, try not to think of hackBytes content as blog posts, but rather a constantly evolving (and very informal) documentation.

In the future, I am going to tackle the computer science field. I eventually want to understand advanced Machine Learning and Data Mining concepts. But one thing at a time. These fields are extensive. For now, I am focusing exclusively on mobile and web application development.

When to use hackBytes?

A new document is published sporadically! When I can maintain a regular schedule for writing new content, I'll update this page with that schedule.

Where to use hackBytes?

Ummm. Anywhere! :-)

Why use hackBytes?

If you want to master programming as well as computer science, hackBytes may serve as a potential resource. Especially if you are interested in mobile and web application development.

hackBytes will contain thorough guides for each of the following fields:

  • Mobile Application Development
  • Web Application Development

Fields to be targetted in the future include:

  • Mac Software Development
  • Windows Software Development
  • Kernel Development
  • Computer Science

How to use hackBytes?

There are several approaches in terms of how you can effectively use hackBytes. Though nothing is stopping you from using a different approach:

  1. Start from the beginning and work your way up.

    • Most time consuming.
    • If you're brand new to development you can gain the most out of this.
  2. Use whatever is relevant to your situation.

    • This is effective when you know what you are looking for. You focus on what you have not yet learned as opposed to spending time on material you have already learned or on things you will not need to know.

In short, while I AM writing everything so that it can be followed from beginning to end, it is not necessary to do so.