2013 has been a year as crazy as others. I changed my job, encountered a slew of terrible recruiters (as always!) and found a place where I like working and plan to stay long-term. Which is great. I also got married, redid my site (several times), made some cash, did some things and voila, I’m here, at the end, December 2013.
Looking back on the top things I’ve learned in 2012, I realized just how far I’ve come, and how far OTHERS have come!
1. Set up separate environments
Up until early this year, I used to just bootstrap things. Running wildly with them. For WordPress, I’d create a dev.* domain and develop there, move the theme over to production and work directly on production from initial launch. No separation of environments whatsoever.
Same with my other apps. I was running a Laravel app and could not get my local system to work just right, and I definitely did not want the hassle of running my database locally so I worked straight on production. Via FTP. Looking back, I worked like a caveman, a homo erectus, and now I’m finally homo sapiens sapiens, the modern man.
Today, no matter what I’m working on, I set up local and production. And staging if I can. I moved my own site to this system via the genesis-wordpress system.
Why did I do this? Because production can break easily, and stay broken. With a production-only dev environment, you’re running the risk of locking your users out for hours. You can’t refactor major parts of the code without possibly breaking everything. There’s no testing. Or rather “testing” is launching features and changes.
2. Monetizing, Correctly
This has to do more with my blog but I’ve learned how to monetize very well over the past year. I average about twenty-thirty bucks a month without doing any work. On my high points I got up to seventy five or a hundred. It’s not much but it’s better than last year when, admittedly, I could have made much more.
My first month monetizing turned out to be a huge success, I made about a hundred.
So what did I do? I tracked. I used Google Analytics and the GA WordPress plugin, set it to track outbound links and checked out what my users were clicking on, what interested them. My number one hits were to BootTheme.com (unmonetized tool at the time, now monetized without affiliates), and WrapBootstrap. WB has an affiliate program so I signed up, slapped my link back on my page, and started cashing in.
Next, I realized that I often “mini-reviewed” the products I used and never linked to them. I decided to go ahead and link to the affiliated home page. I also decided to do full-scale review, always making sure to let everyone know I’m an affiliate. I was also ALWAYS HONEST.
So I learned that. Monetizing based on my users’ existing behavior + my own behavior, using affiliates and ditching over-adsensifying and spamming my site. Today, you’ll see two ads on the right side, and one at the bottom of the article. That’s it.
3. Version beyond just version
I’m not new to Git. I’ve been using it but rather than using it as an active collaborative tool, I’ve been using it as a “backup”. A few years ago, I got into using version control via Mercurial and using Bitbucket. I used it to track my progress code-wise between projects, and not relying on production/local copies of my code. I moved over to Github to post my open source projects and since then I’ve been using Git.
Yet, it wasn’t until this year that I started using Git in a professional setting. My open source projects were scrutinizingly tracked while my professional projects often received a “let’s commit once a week just to make sure I have a copy” type of treatment. I hated digging through Git commits and liked my “commit per version” strategy. So this year, I changed all that. Every change gets committed. My machine seldom has “modified but not staged” content on any project. I believe that to be a bad habit.
So that’s just the “version control”. Guess what I version on top of that? My “stack”. I pretty much throw a vagrant machine on most of my projects. Not only to have a local environment but to have “requirements” written down. Package managers seldom include information about what server my application was developed on, what version of MySQL I use, and what PHP extensions I need.
Anything else? Sure. I use Migrations and Seeders much more often than before, making my database structure as well as data-examples part of my versioned workflow.
Anything else? Yep, one more thing. Since I’ve started using GruntJS, I’ve been able to version just about EVERYTHING I do on a project. Creating a task like “grunt work” and looking over it, I can easily jump back to old projects, knowing full well what it entails.
4. Using package managers
I was reluctant to use bower when it came out and it took working with Genesis Skeleton to get me to actually understand its use and stop minding the ugly URLs.
First of all, I’ve always used packages via the good ole’ “download & folder” technique. Screw everything else. But then I had to deal with Node. NodeJS is the perfect example of package-done-right paradigm. You have a neat definition, packages rest in a place, but they can be overriden. Installation is super-simple as well, same with updating.
I’ve used Laravel‘s bundle package manager for L3 earlier but I never liked it. There were issues with certain bundles and I had to fix them manually every time I updated. I mean, Composer was nice and all but it just turned me away.
Now, however, I’m more experienced and love using package managers. I use Bower all the time, and with Grunt’s help, I’ve no reason to fear ugly URLs. I use grunt to just copy the right files to the right place. Or I get to a point where I just don’t care . And that’s an awesome point to get to. Because having a bower_components folder and “bower_components” in your URL does not make you any less good than your friends. Remember that, kids.
So why Package Managers? To make sure that: you can erase any files that don’t suit you and reinstall them, keep up to date with the right version for your project, keep everything in the correct place (ready to be blown away/updated/installed).
With PHP projects, this is especially crucial. I’m about to update to L4.1. And guess what? If that thing breaks everything and I just don’t want to deal with it, I can just go back a version and do another install!
5. Versatility is crucial
If you read all the above points, you’ll see that this is where I’m headed. I believe that projects need to be versatile and very agile (not like “project management”, more like “movable”) in that, you should be able to quickly replace components, wire up extensions and plugins, destroy it and rebuild it.
Basically, I’m talking about isolating the logic. In the past several months, I’ve built and rebuilt several systems in different languages, all tackling the same issue. Scratch that, I’ve witnessed the prototyping of an admin by me and my co-worker in different languages and different paradigms. It was awesome. Witnessing an application built in different languages helps you understand what is really important about that application.
In my case, the issues on both sides had to do with saving and storing information via a RESTful API that just made sense. The thing is, once we figured it out on one side, it made sense on the other as well. We joked about how we could rebuild all apps in Node overnight because all we had to do was use the same logic, “listen to this, apply this before, then after, this is how, and we need a wrapper”. The end.
I did a prototype for a Bootstrap marketplace for myself in Laravel and then in NodeJS as well.
So what did I learn? Once you tackle the problems, the intellectual “whiteboard” type of problems, programming is much simpler and applications that survive are those that can morph and move.
Looking at applications as “logic” and more abstractly, the same way you look at an “algorithm” and don’t call it an
if loop, helps you understand that application and actually understand programming languages themselves.
6. Full Text Search and Databases
As a naive WP developer turned OOP MVC programmer, I never considered the potential of databases. Just to put this into perspective, I was used to dealing with databases the size of 30-50 rows per table with a max of 10 tables. That’s it.
When I worked for Tech.Pro (very briefly), I got the feel for what it’s like browsing through several million rows of data. Yet it was used in a “lightweight” manner, plus, the lead dev did everything behind the scenes from indexing to full-text search with Lucene. I was as removed as possible. Which makes sense, I was a front-end developer.
Well, I moved on from there and this year, I worked on an enormous database that my application helped populate. To me “enormous” means anything above those measly 50 rows. I ended up with several tables that had 40K rows, several that had up to 80K and having to manage that. On top of that using “like” to search was no longer an option.
Postgres to the rescue. I picked to work with Postgres without really meaning to. I just didn’t want to work with MySQL anymore, it was overdone to me. I thought to myself, “What can I learn from using the same system time and time again?” so I arbitrarily started with PgSQL and it was an awesome option because not only did I learn how to work within that system but I learned to love full-text search, one of its many built-in functions.
So here I go, through my year, creating a database over a gig (REALLY big to me at that point), creating full-text search, balancing index creation with size, and overall, learning how databases can be magnificent to work with, on, and to simply learn about them.
7. Coding is like making love
And in the end, as much as you want it mean nothing, it can mean everything.
I’ve left applications wither before and it’s uncomfortable feeling. I’ve made a starter WordPress Theme that I let die over the past year, despite some attempts at revival. But even more than that, I’ve built up a full application at one of my jobs, spending 40+ hours a week, for months, tending to it, helping it grow, and nurturing it.
In the end, when I left, I had to make peace with the fact that I could not bring the application with me and help it along. I fell in love with it, mainly because I built it. And fact is, I can’t stop thinking about how I would have either rebuilt it or how I would help it along now.
I think to myself: what if I had set it up with composer? What about front-end caching or apc? What if I updated it from L3 to L4? How amazing would it be? What if I had rebuilt the API, the controllers, the routes, and everything else?
I learned a lot from that application yet I learned more when I left it behind.
So perhaps, coding is not like making love but rather like raising a child.
I treat every application this way, giving it my full attention and detail, preparing it for the wild future.
8. Testing gives a peace of mind
I never really subscribed to testing other than manual testing, meaning that you launch a feature, you work with it and hope for the best. Obviously, that’s not the best way to do things.
Earlier this year, I started working at a company that already had a pretty large app on their hands. And properly unit tested. What did that mean? Things that you can easily break via small updates are no longer a concern because there’s this safety. Every day things become much easier to work with.
I’m building my own app right now and the fact that I have not set up tests yet makes me nervous; however, what makes me pretty happy is the fact that once I code it, integral parts of my app will become more dependable.
9. Optimization & Arrays
Some things that I learned last year applied doubly this year. What is it? Optimization and arrays. Okay so, optimization. When you work on your own sites, you just don’t care how many SQL queries you run, you just don’t. So I didn’t either. That was last year, and this year, I took some time early in the year to refactor some major core parts of an application I worked on.
What happened? In some places, I found myself running as many as 69 queries! And sometimes even more. For one page load? Ridiculous. And it was all wasted, stuff that I loaded up, discarded, reloaded. Or SQL statements that I unwittingly threw into a
foreach loop. Nightmare. I refactored the site and went from up to 6-7 second page loads to sub-1 second. I looked at it and I realized that not only did I need to start being careful about using up all the information I get, but also querying for it correctly. Throw a few joins in that query and one execution guaranteed all the data I needed!
But wait. So arrays. I recently started using PHP’s lesser known array functions. I mean look at that list. Anyways, I started sprinkling those beauties into my stuff and not only do statements execute faster when you use those nifty native functions but you realize how much you were missing out on the beauty of the language (inb4 PHP sucks; it has both good and bad moments, okay? Get over it).
Now there’s JS back-end and working in the same language back to front, I realize how amazing it can be. Same language, similar paradigms, similar libraries, and most importantly, same feel to it. Doing an angular front and a NodeJS backend is a symphony, and lives in harmony. Now more than ever do I realize how awesome the language is and that I can’t wait to see where it evolves.
But yes, so:
- it’s everywhere and adoption is rising (outside of the web)
- it’s SUPER EASY but powerful
- working back to front in the same language is awesome as hell
If you haven’t, try it out!
Can’t wait for next year!
I actually started compiling a list of things I want to tackle next year so I’m pretty excited about it. Here’s a preview:
- develop a new wordpress theme optimized for quick loading
- tweak my server and learn about server architecture to be able to improve the loading and efficiency of my site
- start working with C# and Unity3D
- work with Algorithms to set up easy examples for others (and me) to follow.