The following is an (incomplete) cheatsheet / reference from the Loopback Node.js API framework.
In many ways the Loopback framework reminds me of Symfony. It feels very enterprisey and professional. It also has its own terminology and command line syntax which I am constantly forgetting (much like when I learned Symfony!), so this is my work-in-progress reference guide / Loopback cheatsheet.
This cheat sheet is currently for Loopback v2.14.0.
New to Loopback and want to know what it is, and what it does, at a high level, but from a technical perspective? The Core Concepts document was the first document I read that I thought… aha, this is awesome.
Start a new project
Create a new model
slc loopback:model ModelName
Define a new data source
npm install loopback-connector-mysql --save
// and / or
npm install loopback-connector-mongodb --save
Getting TweetHours to v1.0.0 v1.0.6 (ahem) hasn’t been easy. But, it has been a lot of fun. Before going any further though, allow me to give you a little back story.
TweetHours is a mobile app that quickly allows Twitter users to find interesting hours they can get involved with. If today was a Monday but one of the hours you were interested in didn’t start till 6pm on a Thursday then TweetHours will set a reminder for you so you don’t forget and miss out. Then, each following Thursday at 6pm you would get a reminder, and so on.
Now, aside from the technical aspect of building such an app, what has been most interesting to me on this project is that I didn’t come up with this idea.
Mobile Apps + Ideas = Eject, Eject!
Ideas are usually the place I start, but I’ve been bitten by this approach so many times before that this time I wanted to do things a little differently.
The problem with ideas is that everyone has them. And everyone who has them thinks that their ideas are better than everyone elses. It’s one of the psychological phenomenon where we believe ourselves to be better than we really are at everything we do. Male drivers are a great example. We are equal parts Hamilton, Mansel, and Fangio as soon as we are behind the wheel of any motor.
Mostly my ideas are great for me, but they are not viable businesses. They solve my problems, but it would seem that from prior experience, my problems are shared by so few people that they could never be sold at such a scale as to attract a multi million pound buyout and start my subsequent retirement to Necker Island with Richard.
And apps attract ideas like 4chan attracts controversy. Honestly, when asked by anyone what it is that you do for a living, never say apps. People assume this means you must be eager to hear their app idea – which is frequently so vast in scale it makes the modern Facebook infrastructure appear as a mere side project – and then balk at the potential price for building said app starting somewhere in the six figure range.
I’m used to working with clients who have their businesses dictate what needs to be done. I’m also used to building ideas I come up with. In the former case, once the software is built, I am often surplus to requirements and as such, no longer getting paid. Boo. But such is life. And in the latter, well, once I’ve built my ideas I usually find there is actually no market for the tool or app I’ve lovingly created, and so I resign to the fact that simply doing the work was worthwhile so long as I learned something.
This approach sucks, and now that I’m consciously aware of it’s short-comings, I am actively working to avoid it.
Not My Idea, Don’t Blame Me
As mentioned though, TweetHours came about as a result of an apparent need that had not yet been fulfilled. I know, right?! We’ve made it all the way to 2015 and somehow there are still some ideas left that haven’t been turned into a mobile app.
That is to say, a potential customer (not really, I mean my wife) asked me for it. And others in the same or similar fields reacted positively to the sound of it. This is not to say I asked other people’s wives, but rather others in the b2b sector that my wife was working in at the time.
How hard can it be to do a Mobile App Launch?
As mentioned, the app premise is simple. A list of hours, tick the ones you are interested in, receive alerts when they start. Now, I’ve covered already both on this blog and on the tutorials site that in actuality, and of course as any normal software developer will tell you, it wasn’t as simple as it first appeared.
The alerts were tricky. I really should have RTFM more as all the answers to that problem were already well documented.
Getting the imagery sorted was another task. I chose to outsource this and was super pleased with the results. Design isn’t my forte and you really can’t go to market in 2015 with an MS paint monstrosity. And besides, I don’t even use Windows anymore so that would have meant bringing out the gimp.
I built half the app and then took on a couple of pieces of client work. When I returned to finish it near enough a year later I hit so many upgrade issues I ended up starting the project again using the newer dependency versions and porting one file over at a time. Thank God for having the forethought to write a decent set of tests.
Mobile App Launch
Probably the strangest problem of all though was fear. Fear of releasing my app baby into a world full of 1* reviews and Internet crazy. I’d imagine this is somewhat akin to how my parents felt the first time I went out for a drive alone after passing my driving test.
if you build it and then release it, they probably won’t come, but ffs, do release it
So rather than release I set up a beta program. I’d never had to do that side of app dev before so it was new to me.
What a palava.
Google force you into using their Groups setup which is haphazard enough, and then offer no way of giving your app away for free to beta testers. Madness. EA and Dice pulled a similar stunt on me back when Battlefield 4 came out on the pc. Paying full price for a bug ridden crash to desktop simulator left me feeling uneasy about repeating that experience by asking my friends and family to pay to test my app for me.
Still, even though I barely used the beta function, it covered all the same setup required to put the app out into the real world, so it wasn’t a complete waste of time.
I made a bit of a boob in that I accidentally bumped my version in the ionic config to v1.0.0 when going into beta. Hence, the app that has gone live is v1.0.6. What a noob.
I could come up with a ton of reasons I hesitated on going live with TweetHours. I’ve covered just a few. But finally, on the 16th June 2015, I promoted my app to prod.
It felt good.
Now I can sit back, relax, and begin thinking up another great idea 🙂
Side projects are, in my humble opinion, by far and away the best thing that we as developers (not just a PHP developer, a developer in any language) can do for ourselves, our careers / bank balance, and most importantly, our happiness.
Having a day job is all fine and dandy. We have to put bread on the table. And that snazzy Dell UltraSharp UP2715K 27″ 5K Widescreen LED Monitor with its 5120×2880 Resolution won’t pay for itself. Good Lord how I want that. Still, with the pace technology moves at, in two years that kind of resolution will be in your pocket on the iPhone 9… but I digress.
The big problem is that in most instances, the code you are writing for your day job is not the code that get’s you excited.
Let’s not blame the code though. It’s unfair to blame that friendly if / else statement. After all, even if you were writing the software of your dreams, you would likely still need a conditional here or there. Or maybe not if you’re Sandi Metz 🙂
Rather, it is the domain in which your software applies that may not be your dream come true.
But we can fix that.
We can work in our dream domain in our own time. In my experience, few are the software developers who don’t have ambitions of making their own app or software company or dream product. And yet, so few work in their own time to make those dreams come true.
What about tinkering with Redis, Elastic Search, or GrayLog?
No, management don’t understand any of that. And anyway, what are you doing looking at that stuff? Get back to work. There’s a thousand unresolved tickets in JIRA. Marketing need to know urgently whether that div with background-color #9888ce converts better than #a89ad5.
Please don’t put your life in the hands, Of a Rock n Roll band, Who’ll throw it all away
Ok, so far, so sweeping generalisations.
I’m not here to rag on day jobs.
Management may very well have good reason why you shouldn’t be looking into blindly adding new tech to their existing stack. But this can’t be your excuse to sit on your hands and stagnate.
I find it baffling that simply because a technology of interest is not in use in the work place / day job, that this is any reason not to actively try / learn about said technology in your own time. And worryingly I see this attitude time and time again.
But Chris, Learning technology in isolation is a bit dull… I hear you cry.
And I agree.
Sitting down to figure out the ELK stack is a worthwhile en devour, but this largely comes down to reading some docs, having a stab at installing all the component parts, seeing the dashboard and thinking: Great! Then, powering down the VM and never looking at it again.
Because there is no purpose to it. You installed it. It worked. Next.
What is much more interesting is to use the technology in context.
Let’s imagine a happy place where you have taken that app, that SaaS, that dream of being the next Zuckerberg, and you’ve seen it past the first hurdle… that is, you’ve actually started it. There’s some code on your machine that does something. Regardless of how small that something is, it’s a step towards improving yourself, your career / bank balance, and your happiness.
Now, if this project is of any worth, making sure it doesn’t fall over in some unexpected way should be quite high on your list of priorities – especially as your project grows and you and your end-users start interacting with it.
Suddenly your VM with that lovingly built ELK stack has a purpose. Hurrah. Fire it back up, quick. Let’s find a Symfony bundle to make sending messages from our project to Logstash so we get some nice visuals in our ELK dashboard.
Even if your project ultimately gets shelved, the knowledge you have gained from implementing ELK in a real / production environment puts you well ahead of the majority of your peers.
And of course, the ELK stack is just one such example. I use it because implementing logging / monitoring is an inherently useful and transferable skill to have. Setting this up for one project is no different to setting it up for another – whether that be another side project (you used Ansible right, so this is easy and quick to do?) or for your day job.
I’ve worked in places that actively discourage you from having a side project. May I be the first to say – that’s a stupid policy that can only hurt both you and them. And then there are placeslikethese. This reminds me of that story about the brick layer who build his own house in his spare time, and then found out his home was actually owned by his boss at the building company where he worked. Oh yeah, wait, that never happened.
I want to share with you some tips and tricks I have found to motivate myself towards a lifetime of Continuous Improvement.
1. Make a list.
Start by making a master list of all the projects / dreams / ideas you have in your head.
This doesn’t have to be fancy – pen and paper is a great way to start, but of course, there are likely a ton of apps for this sort of thing too.
I use pen and paper as it’s simple and easy, and available to me when I don’t want to be sat at my computer (shock horror).
If your list is anything at all like mine, it will be long and non-exhaustive. That’s great, keep adding to it whenever you think up something new. Simply writing it down will free up some of your limited head space to focus on the here and now.
And again, if your list is anything like mine, one simple line on an A4 jotter could be a year or more’s worth of work. That’s cool too.
2. Chunk in down
For each item on your master list, start a new page and brain dump everything you think you will need to do to make that idea into a reality.
As most of my ideas are ‘software for x’ kind of things, I like to brain dump everything I think I will need to do to get to v1.0.0.
I have never yet managed to write everything down in such detail that this covers every single task I need to do. That’s cool too. This process is a lot like Behaviour Driven Development (BDD) in that you will only start discovering more of the steps to get you to your goal as you start working on achieving that goal.
Try and write down everything and anything that comes to mind. The amount of mental clarity you will gain from freeing up clogged brain space is a very worthwhile side effect of this exercise.
3. Pick Something… Anything… And Get Started
I found that initially, possibly the hardest part is knowing which project to pick.
This is a nice problem to have. However, it can be frustrating.
My advice – pick the one that has the shortest path to v1.0.0.
By writing out each of your dreams / goals, you should have a much better idea of the timescales each project will involve.
If two or more look very similar in terms of time, choose the one that you would most enjoy.
Once you have picked one, look at your list for this project, pick the easiest thing to do from that last, and get started.
Just make sure you get started!
4. The Daily List & The Daily Review
Whatever you opinion of the daily stand up meeting, completing a similar exercise for yourself and your own projects is highly rewarding.
Just don’t do it first thing in the morning. Do it last thing at night instead.
You already have you high level overview, but the day to day may require more technical information, bug fixing, or time consuming bits of admin.
Running through this first thing in the morning is a time consuming waste of energy. Instead, review, re-organise or re-arrange your task list in the evening. That way you can hit the ground running first thing the following morning, or whenever you next get chance to work on your project.
This is similar in some ways to leaving a failing test when doing TDD or BDD. You work to a point, then leave the test failing for your next / current feature, which in turn makes it much easier to get back into the swing of things when you next load up your code base.
Each night you should review your tasks, prioritise accordingly, and be realistic about what can be achieved the next time you will be working on your side project. The very act of making and reviewing this list will increase your personal productivity significantly, and being able to see a check list of ideas, goals and tasks each ticked off on your paper is hugely motivating.
5. Use Technology You Know
Git is probably the single biggest technological win for me in the past few years.
A simple task on your list of daily tasks towards achieving your goals could be to git init a new project, and push the contents of your dir up to your newly created repo. Progress!
The real power for me has been standing up a Gitlab server for my own private projects.
Inside GitLab you can add in task / bugs lists, add in Wiki entries for complex parts of your project, and generally do 99% of the things you can do with GitHub. About the only thing not there is the public’s code to search.
But the most powerful feature of GitLab for me is the Contributions Calendar. GitHub have this, and if you were to look at my profile you would think I rarely did anything.
Not so. I just commit to private GitLab instances a heck of a lot more than I use GitHub.
Keeping that streak alive is a powerful motivator, and it’s built in for free if you use the same GitLab a lot. Of course, you’re free to use GitHub or whatever, but don’t under estimate the power of seeing all of your daily activity in a friendly little widget.
Share Where? Here. There. Everywhere!
So now you have one or more projects you are working on in your spare time.
You’re immediately ahead of the curve.
This makes your resume more complete. It gives you things to talk about inside an interview situation that aren’t blah blah corporate finance payroll software blah blah. And hopefully it’s got you highly excited about some of the amazing open source tech that makes your world a much better place to be.
You can choose to share these projects any way you see fit.
Of course, be careful about this if you do work for a company where side-projects are banned or frowned upon.
Share the source code via GitHub – hey, free side benefit is your GitHub Contributions Calendar will look awesome!
Talk about your project on your blog – you do have a blog, right? If not, add that to your list.
You don’t have to share your source code – talking about what you’re up too is fine, and sharing some code snippets with a bit of context can be equally helpful.
Always wanted to do a conference talk? Great, your side project is likely interesting to others – maybe not the domain in which you operate, but the process and the journey it’s taken you on.
Meet new, like-minded people. Every language has it’s own community. There are some real lemons in each one, I’m sure. But don’t let that put you off. You will highly likely find some amazing, like minded friends amongst them.
If your passion is coding, do it every single day.
Working on code / in a domain that interests you is much more motivating than coding for a pay-cheque.
As software developers we can build whatever we can dream up.
Dream up something – anything – and get started. The journey is just as important as the destination.