My developer tips and tricks

A list of tools I cannot imagine working without, and a few tricks to help you debug your code.

Every developer has a set of tools he likes to work with. His own bread and butter so to speak. I thought to rest from the usual tutorial a week a bit, and write about the tools I use for development, and some tricks that can help you find out why you code doesn’t work.

In a month it will be 2 years from my first web development job, and my first real encounter with the development process. Looking back at it I see that I’ve learned a lot. But also, when I read stories from other developers, I see how much there is to learn. I don’t know why, but part of me still doesn’t see myself as a ‘real developer’. In my family it was always my dad and my sister who were code savvy. I was never good with ‘big’ programming languages. I learned C and Fortran on uni, and I hated the dry and boring syntax and the way they were thought (maybe I hated them because of the way they were thought tbh). Later on I dabbled with Python, and I liked that I could do something ‘more tangible’ – like my best question on SO – finding the average sunspot count and graphing it out. I guess it was the fact that I could actually see my results. The same was with Wolfram Mathematica, in which I did much of the calculations for my masters thesis.
So in the end I guess it took me a while to find the one programming language I really liked. And I found it – JavaScript.
What I like the most about it is that I can write a piece of code and immediately see the results. Something will happen when I click a button, or scroll a page, or even swipe the screen on my mobile phone. The clear way that you can see what your code does is what drew me in I guess. I was always a visual guy :D
I didn’t learn JavaScript on its own. I read some books (I recommend Head First JavaScript Programming by Eric Freeman and Elisabeth Robson), but most of it I learned by working on WordPress themes (hands on approach really is the best). With that came not only JavaScript, but php as well. I learned a lot in that area as well – pulling data from the server, manipulating databases with mysql queries, writing functions and learning to write code in object oriented way (this one I’m still learning and I find it really interesting, especially when developing plugins).

When I started out, I coded a little bit. Since I came from a scientific community, I didn’t use any developer tools. The only thing that I used, which you could consider a web developer tool was Notepad++. While it’s still super fast source code editor, I moved on.

The Editor

I remember my boss asking me on the job interview: which code editor are you using? I answered Notepad++, and he said that he prefers SublimeText. I’ve never heard of it before, and naturally when I got home I immediately started googling and seeing what the fuss about it is. And oh boy, there was a lot of fuss. Fist thing that drew me to it was the way it looked (of course xD). It was dark, and the code stood out nicely against the background. But there was more. Apparently there were all these super shortcuts you can use to quickly search selected parts of the text, you could easily duplicate the entire line of code without selecting it, and so much more (see the cheat sheets for ST3 on OSX, ST3 on Windows, and ST2 on Windows). My mind was blown away. Later on I discovered that you can enhance your Sublime editor to your liking. The possibilities were endless.

SublimeText 3 editor

The current look of my Sublime Text editor – I’m a sucker for a good look :D

Today I work on Sublime Text 3, with these add ons:

As you can see I added those packages that benefit me in my daily workflow. Minus the theme – this is a personal preference.
There are a few things to mention here. For linters to work, you’ll need to install them first using Node.js (and npm if you’re on Linux). The best thing is to read the official documentation, and documentation on jshint (csslint can be installed in the same way). Also my advice is to follow the official Githubs of the packages you’re installing. You can report any issues or bugs you find, see solved ones etc. My user settings for Sublime Text is

You can modify yours if you will. Also my linter settings are:

These were a bit of a trial and error based settings, until I found the ones that suite me the best. DeleteBlankLines will speed up deleting unwanted empty lines, Alignment will help you quickly align your code so that it looks prettier and you’ll navigate through it a lot quicker. Emmet is a great tool that will speed up your HTML writing, as well as css. For instance, in your .css code, just write pb10  and hit tab, and you’ll get padding-bottom: 10px; right away. A true time saver. There are tons of useful packages out there, just google it a bit and find out which one you think will help you the best.

Alternative editors are the aforementioned Notepad++ and Atom.io which is a rising competitor to Sublime. I was tempted to try it out, but realized I got accustomed to Sublime’s shortcuts and packages, that I really didn’t want to change something that isn’t broken.
Sublime Text has a licence that you can buy, but it will work fine if you don’t (every now and then you’ll get a screen saying that it would be nice to buy it, but you can close it if you want to). Of course you should support the developers doing the good work, and if you can afford it, buy it by all means.

Developer Tools

Any front end web developer should be accustomed to the Developer Tools. I use Chrome’s built in Developer Tools that you get by either right clicking on an element and inspecting it, or hitting F12 on your keyboard. Depending on the browser you use you can use different developer tools. Firefox has a built in one, and a popular extension called Firebug, which will allow you to track any bugs in your code. The same is with Safari, although I think that the ones from FF and Chrome are more powerful.

Chrome Developer Tools

Chrome Developer Tools – en essential tool for any web developer

What dev tools allow you to do is to see if any of your JavaScript code is producing an error, see and edit live any source code you can, see the network activity which comes in handy when you want to figure out what could be causing your site to be heavy and slow (like a big image for instance), or see the response from your ajax call, and many many more things.
I have been using them from the beginning, at first mostly to change the style of my elements – you can easily pick a color with the built in color picker, toggle hover or active state etc. But for me the greatest thing you can do with them is intercept and see which part of the code executes on a certain event using DOM Breakpoints. This gives you the power to see the code execution step by step, which will help you immensely while debugging. There a lot more you can do with them, and you can read it all on the tips-and-tricks  page. There are even extensions like Emmet LiveStyle which enables you to edit your css real time – what you change in the inspector will be written immediately in your css file – also a time saver.

Another cool feature is the Toggle device mode which will roughly emulate your page or app, so that you can see what it looks like on different devices. One thing that you’ll have to be careful is not to depend on it 100%. It is just not accurate. When working on responsive layout, things can look good in the emulator, but once you look at them on your device the results can be pretty different. This applies the most to emulating Apple devices. I still haven’t found a good emulator for iPhones. The closest thing I’ve seen is BrowserStack, but they are not emulating your page. They are actually providing you with the real snapshot from the device itself. This is why their services are not free. There is a free trial, but the device range is limited, as well as the time you get. The advantage is that the view you get from them will be the real view from the device you picked from the list, the downside is that, if you’re a freelance coder with a limited amount of money to spend, it’s pricey to pay $29 or $59 per month. Unless you’re really successful and the money isn’t an issue, then go for it, it’s still way more cheaper then owning the most popular (and the most used) Android, Apple and Microsoft devices.

The great thing about Chrome dev tools is that you can connect your Android device to it and inspect it. Same thing goes for Safari and Apple devices. This is however one thing that Apple does better – connectivity. Apple is a closed system in a way. What this means is that it doesn’t play well with others, but it plays perfectly with other Apple devices. So much so that once you plug in your iPhone to your Mac, you won’t have to install any kind of drivers, and you’ll be able (once you enable developer mode in Safari) to inspect the mobile phone or tablet in it instantly.
With Android it’s a bit complicated, especially on Windows OS. First you need to install sdk drivers. Once you do that, you’ll need to enable developer mode on your Android phone, and then connect it to your computer. Next you’ll type  chrome://inspect/#devices in your Chrome and… you probably won’t see a thing. If you do, count yourself lucky :D If you don’t, do not despair, there is a workaround.

First you’ll navigate to your sdk installation folder using the command prompt. Then you’ll want to get in the /platform-tools folder and type

This should, hopefully, kickstart the Android Debug Bridge and you should see your device popping up in the inspect tab. If it doesn’t try first by ‘killing’ the adb server

And after that, type the first command to start it.

Command prompt

Kickstarting the adb in the command prompt in Windows

Mobile inspect

Mobile inspect – a way to debug your Android phone in Chrome

After that you should see your device and once you load the page on your Android phone in Chrome you can inspect it live, and adjust anything you want.

Debugging

Debugging is something that every developer has to come to terms with. You can write beautiful piece of code, and it can even be without bugs on its own, but you need to realize that most of the time, your code won’t be ‘living’ alone. Especially when you’re working on WordPress themes or plugins. There will always be another plugin and some piece of code that can mess your functionality up. And then you’ll need to pinpoint the reason this happens and fix it. This is the essence of debugging – finding the problem as quickly as possible and try to find the best fix.

When developing a theme or a plugin for WordPress, the first thing you’ll need to do is to enable debug in your  wp-config.php by setting

This will catch all the notices, and some of the errors you may have on your page. Sometimes, however, this won’t be enough. So you can add

Right after the debug define. This will write any error you may have in  error_log.txt file in the root of your WordPress installation. For instance, two weeks ago I was writing an article about loading posts using AJAX. To be sure my code is ok, I tested it of course. And to my surprise after some time the code stopped working. I was getting 500 Internal server error in my inspector. I looked at both my .js and .php code but I couldn’t find a thing! The code was the usual one I’ve written over and over, and it was always working. Why didn’t it work this time? Since I got 500 error, I couldn’t be at fault. It’s server’s fault! So I mailed my host provider, and they responded saying that they don’t see any issues on their end. I was sure my code is correct – the error is a server one, not mine. I was sure my code is just great. We changed physical server, looked at the logs, everything. But I couldn’t figure out the issue.
In the end I said that we’ll leave it like that and I’ll have to see what else could be the issue. And the issue was – my code. Of course it was.

AJAX, unlike traditional code, works by fetching the data you’ve send, if you have an error you can catch it by putting in your  error method:

This will give you the full error code and details in your console. This time it didn’t help sadly. But I googled and found that I can write to my error_log.txt file. This saved the day. It turned out that I had forgotten to declare an empty array for the categories, so I was trying to push string to a variable that was itself a string, not an array. Even here I had the same 500 error. Here the issue was in an undeclared function in my ajax function. Once I’ve fixed this the loading started working, which immediately brightened up my day (in spite the fact that it’s raining at the moment xD).

There are two analogous functions that will help you with seeing what your code does. I use them all the time. In php the function is

print_r() will print out a readable information about your variable. If you’re not sure what your variable contains, just do a print_r() and you’ll see all the information you have at your disposal. In AJAX functions, you’ll put it inside the wp_die() function if you want to see it on screen or inside the Network tab of your inspector. You can use var_dump(), but I prefer the cleaner print_r() .

Similarly for JavaScript you have

If you are calculating element offsets or widths, you can put your variable inside it and you’ll see the results in your console. This is really helpful if you’re not really sure if the code you wrote will return the desired thing.
Debugging the JavaScript is also done by adding break points in the inspector and seeing what happens when the code executes one step at the time.

Testing environment

When you are developing your code you want to test it of course. First you want to develop your code locally. For that you can use XAMPP, WAMP, Vagrant, or any similar tool. So far I’ve successfully used XAMPP. I’ve tried to set up Vagrant, but it proved to be more difficult, so I cannot say about using it. But the idea of it is great, as you can set up the exact development enviroment like you’d have on a real server systems, using Ubuntu or CentOS for instance.

For WordPress development you need to check out an article on Hongkiat about 12 Essential Plugins for WordPress Developers. Theme check is a must if you want to publish your themes on WordPress.org, and ThemeForest has a similar plugin. Debug Bar shows a debug menu to the admin bar that shows query, cache, and other helpful debugging information. Query Monitor can help you identify any slow query you might have on your site, so that you can optimize it.

There is a good article about unit testing that I recommend you read. It is old, but it’s good for the beginners.

Conclusion

I’ve shared with you how I develop my code and the tools I like to use while doing it. I hope this helps any fresh new developer out there on a way to becoming a better one. I realize that I myself have a lot to learn, but it’s a process I look forward to – learning new way to improve yourself is always a great thing.
Feel free to share the tools you like to work with, testing tools and tricks you use, in the comments below. Until next time, happy coding :)


Also published on Medium.

Join the Discussion