I just found a site that attempts to create regular expressions based on sample input. It then does predictive analysis to spit out a guess as to what kind of regular expression you’re trying to build, to save you the time to build it.
How awesome is this?
My priority at the present time is to somehow get my local community engaged in learning about technology and using this knowledge to build new things with that knowledge.
There is a huge opportunity at the moment – perhaps unmatched at any time in history? Someone correct me here. The opportunity I see is the ability to learn real world skills with the only barriers to entry being:
- a computer device such as a tablet or laptop
- motivation to learn
To get started, one doesn’t even need a high powered computing device. Second-hand is fine. There may be limits to what you can achieve, sure. But, maybe not.
What can come of this?
Build an app. Build a blog. Build a better mouse trap. Write ‘Choose Your Own Adventure‘ Books as an app or as a web site. Use your imagination. Go on.
To learn something new, you need a good teacher. Here’s my favourite teacher and community: Free Code Camp.
What’s Awesome About It?
If you have a use-able computing device, the only barrier(s) to entry are those that you create for yourself. So, get started. If you don’t have your own computing device, you may be able to use resources at your local public library.
How You Can Benefit
- Join a community of over 300, 000 members. Across the world.
- Work with and learn from others.
- Build real projects and put them in your portfolio
- Learn skills like Front-End Development, Data Visualisation, Back-end Development and Full Stack Development. At your own pace.
- Learn state-of-the-art technologies:
- Get help in real time from your community.
A Cautionary Tale
So, I upgraded to Intel XDK build 3088 today (from build 2893).
And I’m in the middle of building an App.
But I’m brave.
Here’s some things I learned:
- You may have to rebuild your app. I’ll just say it. Rebuild your app. This article still works as to how (you don’t get “enoent” errors anymore – instead you can expect all new and improved errors).
- My favourite way to install custom plug-ins no longer works. That’s OK. There’s a solution here.
- When your build is successful – on iOS at least – the file extension is no longer included. I’m adding ‘.ipa’ manually in order to install my adhoc build to iTunes for testing on my phone / tablet.
- When starting again, I used to like building a new project sans-Cordova, and then upgrading the app on the fly to a Cordova version (it used to be ‘cleaner’ that way, if you will). No. Not any more. Now, it is best to build a new project as a HTML5-Cordova project from the outset. Or, no “onAppReady” for you…
- screen-orientation plugin only works in CLI 5.1.1. Reference to solution here. Except in my testing, it no longer seems to work consistently.
If I find out any more sneaky quirks or problems, I’ll let you know. Frankly though, Intel XDK continues to march onward in the right direction. Sure it’s annoying to rebuild my project from the ground up, but from the most part that’s a copy and paste in the files system and a manual copy-and-paste of the content of js/app.js and a manual copy-and-paste of the content of index.html. And yes, I’m not wild about the RSI that I get from clicking on all those icon and splash-screen settings – but if I was less lazy I’d hack the XML direct. Or something.
For those who are not yet up-to-speed: cross-platform-app development is a reality. Sure, it may not (yet) have all the fancy-pants bells-and-whistles of native App development kits. But it’s really close. Unless your App absolutely requires a particular feature only found in a proprietary software-development-kit, consider XDK’s (cross-platform development kits).
- Intel XDK or PhoneGap / etc.
- Research (complexity / competition / App-store policies)
Once the prerequisites are completed, create a sandbox of your App on your local machine. My folders follow this basic pattern:
The Mighty Sandbox
My SANDBOX folder holds my ‘sketches’. The screaming upper case of the sandbox’s root folder name is purposeful. It can’t be missed.
Now follow these steps:
- Build the user interface and as much functionality as is feasible that can be performed without the use of Cordova plugins. (Cordova plugins work on a smart-device, not in a sandboxy, webby environment).
- Make a backup of the sandbox environment at least once per day. Generally, this can be done by zipping the project folder. The zipped sandbox project can then be versioned and copied to a cloud service as a further backup.
- Once the sandboxed App is complete (and the last backup has been safely archived), I will then copy the semi-working to working file assets to a folder outside of the SANDBOX folder, but now directly under IntelXDK (I build in Intel-XDK’s environment).
- On an at least daily basis, I’ll create backups of the production-space project, same as the sandbox’s naming pattern. These zip files will be placed on the cloud, but in a production backup folder (and not in the sandbox’s backup folder).
- Once the App is complete (and by complete, I mean for sale on App stores), I’ll then clean up the archives by deleting all of the old sandbox and production zips – except for the most recent zips. So, I’ll keep one sandbox version (the very last before moving to production), and the last production version. These are now renamed to ‘v01’ of the App. Should I create an upgrade, the last production zip will be where I start, and the user interface and code that doesn’t rely on Cordova will be placed into a sandbox location, where the cycle will start anew. The next released version will be ‘v02’. Probably.
What I’ve learned from this process
- Toggles in fancy frameworks are not working for me – still! Buttons it is. Sigh.
- Apps can be moved back to the sandbox if necessary.
- Working code can be retrieved from any previous version, including from the sandbox. Yay!
What’s not perfect?
Do I make a backup every day? No… Shame, shame, shame. Seriously, don’t be tardy on backups.
Where is my code? I’ve got, like, 20 backups to choose from (six backups always feels like 20)! This scenario happened to me on my very first App. I’m sure it’ll happen again.
Got any tips or advice? Feel free to comment below!
OR “What To Ask Before Putting Finger-tip To Keyboard”
For the purposes of this document, I’m going to use the term “App” to mean either “Game” or “App”.
App development is for me both a joy and a commercial venture.
At the moment, I try to develop Apps with the following goals in mind:
- it should do one thing very well
- the underlying complexity should be hidden completely from the purchaser
- ideally, the purchaser should be able to use the App without needing to refer to the “how to” documentation
- the documentation should be clear and concise and only one click away.
I sometimes develop an App strictly to play or to learn. Even when playing or learning, I usually have an end goal in mind, meaning that any code I write will be written in a manner than can be easily re-used and with the view to be used sometime in the near-to-medium future in an App.
Unless I’m developing strictly to play or to learn, and before I put finger-to-keyboard, I conduct research.
Steps to take before Starting to Build Your App
- You need to have an idea for an App that you wish to build.
- Are you almost-to-absolutely certain that you can build this App with the skills you possess?
- What plug-ins will you need (eg. geolocation, insomnia, inappbrowser etc)
- What plug-ins won’t you need (that is, make sure the complete list you made in 3 is absolutely necessary – don’t acquire more than you need – that’s called ‘bloating’).
- What development libraries will you need? Do you have permission and budget to use these libraries?
- What frameworks will you need? Do you have permission and budget to use these frameworks?
- Find out how many Apps do the same thing as the App you’re thinking of building
- Don’t despair if there are hundreds of Apps that do the thing your App is going to do
- Be mindful of the amount of competition your App will have never-the-less
- If the market is saturated, move on to your next idea. It can happen.
- If the market is saturated, and you want to deploy anyway, remember Homer Simpson’s logic on competition (taken entirely out of context):
“But what about the victims? Hardworking designers like Calvin Klein, Gloria Vanderbilt or Antoine Bugle Boy? These are the people who saw an overcrowded marketplace and said, “Me too!”
- Even with your new-found, Homer-fuelled self-confidence, your App will always require a point-of-difference if it isn’t unique in the world. Make sure you have a point-of-difference.
- What are others selling their App for? (Your point-of-difference may be your price point by-the-way).
- Units – can you estimate how many units your App might sell? You should be able to find the largest seller in the space you’re competing in (in each store you’re thinking of selling in). You may also be able to calculate based on the size of the market place (eg. total Personal Trainers in my country equals X, and if I sell to a likely percentage of them, I’ll have sold Y units, at a price-point of P, given a total of $T, not including starting costs, App store margins and any API costs etc etc).
- Will you make a satisfactory amount of money according to what you found out from the previous point?
- Do you have the time required to build this App?
- Give yourself a reasonable deadline. You need to meet this deadline. Development is a discipline.
- What minimum features must your App have. Cut this list down as you code (you may run out of runway – there is always room for another release. Keep your customers hungry for more).
- Keep a note of features that didn’t make it into this release (it makes it easier to remember if you decide to come back to the App for the next release).
- Will your App idea be acceptable according to your understanding of all published App store policies and guidelines?
- Planning is ugly. Don’t forget to remember this point in order to get over it.
These are basically all of the points I can think of that make up my decision chain when I’m planning to build an App. Apart from that last test, if my App does not get built because it fails any one of the earlier tests I will document the idea and then park the idea. I will then move on to the next idea.
Keep in mind a “parked” App idea may get put back on to the agenda because of any number of reasons. Maybe a new framework, library or tool appears in the market that might make the App feasible now. Maybe a competitor retires from an otherwise profitable market place (it can happen). Maybe you can figure out how to deliver a unique point-of-difference. Maybe the competition isn’t as fierce as you first realised.
Maybe you simply found the time.
I do not let the last test in the decision chain get in the way of my resolve. That is why the final test is in that particular location in the decision chain. If I can’t resolve that final test and move on towards building the App, then there is a larger problem to deal with.
Do you have anything to add to this decision chain?