Emacs, we’re on a break

Back when I started programming, around 15 years ago, things were simple. You’d use Notepad to write HTML/JS, and Visual Studio to build things in C++/Visual Basic. A few years later I got connected to the internet and discovered a whole culture around programming, and along with that came the endless editor wars. The glorious editor wars

Discovering the one true editor

Imagine a kid, who just got started with programming, being exposed to the idea that some editors were better than others. Not just that, but the subtle hints that good programmers only use Vim/Emacs. You use Notepad? Hmmpph. You must be new to this

Well, there I was, about 15 years old, being told that real programmers used Vim/Emacs; because it makes them faster and better. Of course I jumped at that! I could be a better programmer just by learning a new editor? Why not!

It started out innocently enough. I tried out Vim, then I tried out Emacs. Didn’t really like either of these, so I tried out Netbeans/KDevelop/Notepad++/Komodo Edit and a few other contenders. I think I settled with Notepad++ for a year or two.

But there was always that nagging thought in the back of my mind, real programmers use Vim/Emacs.

A few years later I was a student in university, and I had a lot of free time on my hands (weirdly I didn’t do that well in university, never found out why though!). I think I must have read more than 500 articles on the pros/cons of using Vim vs. Emacs.

Most of what I read made it seem like this was the choice of a lifetime. You were either a Vimer or an Emacsian. You would never use both. So understandably I took a long while to make this decision, reading all the article I could to better understand what I was signing my soul over to.

I eventually settled on Vim, probably because I couldn’t remember all the different C-n, C-p, C-x C-s key chords for Emacs. Vim just seemed easier with it’s modal editing mode. So I focused all my energies on Vim, and for the next few years, I would come to both love and hate that gem of an editor.

The pains of growing

I used Vim as my main editor for around 8 years. Even though learning to use Vim enough to be productive in it was a painful and difficult process, it brought a great ROI. Once you grok Vim, using it is a pleasure! You see patterns in your text, and you intuitively become aware of the series of key-strokes needed to accomplish the edit you want.

Want to change a dictionary key lookup in Python to an attribute accessor? From dct["key"] to dct.key, just use ds[ and ds" and insert a .. That first two series of commands use the surround.vim plugin by the awesome Tim Pope. He has a lot of other great plugins as well that make Vim an even more awesome editor that it already is.

Like most Vim/Emacs enthusiasts, I have probably spent at-least a month of my time on customising and improving my Vim setup. Up until 2013, Vim was the best editor I had ever used. I was still learning a lot of new languages, and only programmed in my free time and for fun. I didn’t care that I had to lookup documentation for Django class based views every 5 minutes because I was learning and having fun.

It also didn’t matter that after using Komodo Edit and seeing how useful the autocomplete was for a new programmer like me, I still went back to Vim. Why? Well, because that’s what real programmers use.

I was young, naive, and didn’t really have the ability to think for myself and go against the culture I saw on the internet. I wanted to fit in. I wanted to brag that I used Vim, the editor of the gods. I could write a macro to convert that HTML table into a Python list in 1 minute, a task mere-mortals would take 15 minutes to do. In my programming career of 15 years, I’ve done that maybe three times.

That was fine and well for someone who only programmed on side project, and small freelance gigs that were never more than a few hours or at max days of works. But in 2013, I started my first job as a professional programmer at Dubizzle, the largest classifieds site in the Middle East region. It is a Django project.

Loosing my innocence

Dubizzle was a huge codebase, with a lot of legacy stuff and a lot of files. Until now I had only worked on small projects, composed of between 1 and 10 files. Code navigation was never an issue.

But Dubizzle was a different beast! With more than a 1000 files, it was impossible to navigate between them by memory alone. And given how legacy the code was, it was immediately clear to me that my Vim setup wouldn’t be of any use here.

My team lead at the time used PyCharms, and he was a fan. He was like a really annoying fan that tried to pushed PyCharms on everyone! I was that way with Vim as well. Can’t really blame him, we programmers tend to make emotional attachments to a serires of 0s and 1s for some reason.

Anyways, after trying to use Vim for the first 2 weeks and failing miserably, I started using PyCharms. But I didn’t move to it. This was just a temporary solution. I had found a small group of people at Dubizzle that used Vim successfully, and I fully intended to replicate their success. Of course I’d move to Vim, that’s what real programmers use.

It took me about a year to finally get around to setting up Vim. I had almost 20 different plugins installed, and after a month or so of effort, I had my ideal setup! I could use Vim on the Dubizzle codebase. Life was a bliss, and I was finally using what grown up programmers use to code.

Of course, even after the month of effort, the setup wasn’t nearly as good as PyCharms for project navigation, or code completion. Or any kind of help with writing the code either. Jedi worked, but failed sometimes. Virtual environments were weird to figure out, and PyCharms figured out stuff about the code that Jedi just couldn’t get, like the return types of functions. It also had other great features like jump to a class, rename variable, find usages, and a whole lot more. PyCharms (and to my knowledge all IDEs by JetBrains) are a pleasure to use, and seriously great software.

Looking back, it’s feels weird that I spent a month of work trying to replicate something that already existed. But man did it feel good to work out of a terminal again, with only 256 colours and weird key combinations, no real popups (for code completion). But I could work without taking my hands of the home row.

A new hope

After 1.5 years at Dubizzle, I moved on to JRD Group, a kickass startup. I joined the team that was going to build a new version of JustProperty in Django. The older version was in PHP *creepy music*.

Given the time I had spent on making my Vim setup solid enough to work on the Dubizzle codebase, I had no problems with using Vim as my only editor for the entirety of my time at JRD Group, which was around 2.5 years. Since I was part of the team that started the project from scratch, I remembered where almost every class was, where a particular feature was coming from. I could (and still can) navigate the entire project by memory alone. For this, Vim was perfect. I still remember this time as the best Vim experience I have ever had.

Everything was working perfectly. But there was this guy with me at the team that used Sublime. He could navigate to a class in the code with a beautiful interface. He could run a project wide search without needing to install an extra plugin (I used Silver Searcher). And my God did the colours look gorgeous. Plus the multiple cursors!

I tried out Sublime for a bit, and to this day I still use it for small one-off scripts and quick text editing. It’s solid and good at what it does.

But I wasn’t ready to give up on Vim. I had heard of this new thing called NeoVim. It was a mythical creature, one that had background threads for plugins, could be programmed with a sane scripting language (which VimScript is not!), could run a terminal inside itself, and supported somewhat beautiful colours (after some weird terminal config). Of course I moved. I guess I must have spend a week of effort on configuring NeoVim. Deoplete is an awesome completion framework. I had true colour support in Vim. It was an exciting time.

And then, I moved to Emacs.

The Emacs days

I somehow stumbled on to this video about Evil Mode. I was interested, so I though I’d give it a try. I installed Spacemacs, didn’t like the fact everything was pre-configured. Next I installed vanilla Emacs and installed evil mode. But that too didn’t feel right.

I decided I could stick to Vim or learn vanilla Emacs and configure it my way. By this time, my day to day work involved a lot more DevOps stuff, and only some coding. This seemed like a good time to learn a new editor, when my daily job didn’t depend so much on my typing speed.

So I installed Emacs, worked through the tutorial in 2–3 days, and started configuring it. Here was an editor that had one of the best scripting languages I had ever seen; Emacs LISP. And it was extensible as hell. I probably spent two weeks setting it up. Magit is awesome! So are the twenty other plugins I installed and configured. I was in love again.

And this time around, learning Emacs wasn’t difficult. I was extremely surprised by how easy it was for me to pick up a new editor. For some reason, I had gotten it into my mind that having been a Vimer for almost 7 years, Emacs was a no-go area for me. But I was so wrong. I picked up Emacs and got to 75% of my Vim productivity level within 3 weeks of using it. I still miss the move-to-character command from Vim though. 🙂

Then I discovered Org-Mode, and my life hasn’t been the same since! It’s by far one of the best to-do managers I have used. And there is so much more to it than being just a to-do manager!

Emacs had a built in terminal. NeoVim just got that a while back, and it’s still nowhere as great. But getting Jedi to work with virtual environments is still a pain in Emacs. Refactoring is still not as great. I didn’t have the jump-to-class-in-project figured out. While the editor was awesome, using it for Python was decidedly only as good as I had it with Vim.

A new job, a new start

I recently started a new job. It’s been two months now, and I’m working on a brand new Django project now. I have been using Emacs for the past 4 months. But I’m still not happy with it. Jedi is a good autocomplete library, but it’s not perfect.

Finally, after 15 years of fighting it, of trying to fit in, a week ago I had to give up. I can’t keep telling my self that Vim/Emacs is the only editor I should use if I want to be a serious programmer. Yes, I know my setup for Vim/Emacs could be way better than it is. But I’ve spent enough of my life trying to tweak the editor to work with my language of choice. Emacs is a great editor, but I can’t keep spending my time tweaking it to work on the same level as PyCharms.

I’m done making excuses for why I use Emacs/Vim over PyCharms. I might be able to edit that line 5 times faster in Vim that I can in PyCharms, but if my experience with Emacs taught me anything, it’s that the editor doesn’t matter as much as we’d like to believe.

As programmers, we’re told to use the right tool for the job. I have finally realised that Vim/Emacs aren’t the right tools for Python/Django. For me at least. For Golang, I haven’t found anything better than Vim. For general notes and to-dos, Emacs with Org Mode is the best. Magit is the best Git frontend I’ve seen. I prefer using it over the Git CLI. For editing files that are GBs in size, Vim blows everything else out of the water. For Clojure (which I got interested in because of Emacs LISP) Emacs is straight down the only thing I’ll consider using. And I’m sure that for other statically typed languages like Rust, C, C++, Emacs and Vim are crazy awesome, and I’ll probably use them over anything else. But for Python, PyCharms is the best I’ve seen. And I’m going to give it a try now.

Yes, true mastery of an editor will give you maybe a 50% boost in editing speed over how I today use PyCharms. But I bet that gap will close over time.

If I can learn that C-c pf opens up Projectile file navigation, I guess I can also learn that Shift-Cmd-O opens up the file navigation in PyCharms.

And even if, at the end of 6 months, I’m still not able to edit files in PyCharms as quickly as I was able to in Vim/Emacs, I’m OK with that. My experience tells me over and over again that typing speed doesn’t matter. That’s what a lot of other smart people say as well. I guess it’s time I listened to them.

Takeaways

I guess this is just a rant, something I had to get off my chest for a long while. I’ve had arguments with many people over why Vim beats their editor of choice. This is my way of accepting that they were probably smarted than me in their choices.

This is my way of accepting that I don’t need to use Vim/Emacs to be good at my job. That it’s OK to not follow the culture when you can’t seem to fit in. And this is my effort to help the next 15 year old who searches for “Vim vs Emacs”. Don’t worry about it. Use whatever feels natural, and works best for the environment you’re working in.

I will keep using Vim on the remote machines I manage and for Golang. I will keep using Emacs for Org Mode. And from now on, I’ll use PyCharms for Python.

One of the surprising discoveries during this journey for me was just how limited I believed my abilities to adapt were. I had convinced myself that I could never move to another editor. But after using Vim for more than 7 years, moving to Emacs successfully over a period of less than 2 months opened up my eyes.

I hope I have the same luck with PyCharms.


P.S: You can find my dotfiles, which hold all the Emacs and Vim config I use, on the Github repo.

Reboot DigitalOcean droplets from the command line

At work we use DigitalOcean VPS for deploying our software (JustProperty.com). As the DevOps guys, I’m working with these servers on a daily basis.

Today I needed to reboot a bunch of servers. While I love DigitalOcean, their web based control panel leaves a lot to be desired. It would take at least 20 seconds at least to reboot one server from the web app. You’d need to find it in the list of droplets, open up the detail view page for it, then reboot it. So instead of spending a couple of minutes doing that and moving on, I spent an hour figuring out how to do it from the CLI. You might call me crazy. I call it gaining efficiency in the future. 🙂

I usually use the awesome doctl command line utility to manage similar tasks from my terminal. You can get it from it’s github page. But doctl only allows restarting one node at a time, but not multiple ones as far as I could find.

I knew I could use xargs to run the doctl command on a list of droplet ids. I also knew I could get the droplet ids using doctl compute droplet list 'NAME-PATTERN'. Combining the two, you get:

doctl compute droplet list ‘NAME-PATTERN’ | cut -f1 | tail -n +2 | xarg -n1 doctl compute droplet-action reboot

Which allows you to restart multiple droplets with just one command. Mission accomplished!

Btw, the name pattern is used to match droplets by name. For example if you have a bunch of web app droplets, a pattern like web-app-fe-* will match any droplet with a name that starts with web-app-fe-.

P.S: I initially did something stupid. Yup, I said it, I was stupid!!!

So my initial efforts somehow lead me to use this command to get a list of droplet ids for the droplets I wanted to restart:

doctl compute droplet list ‘NAME-PATTERN’ | cut -f 1 | tail -n +2 | tr ‘\n’ ‘,’

This of course returns the list of ids in a single line separated by a comma (,). Since the droplet-action reboot doctl command doesn’t accept multiple ids this way, I had to find a way to split this string of comma separated values into multiple lines. Learning how to do that took a while, but as always, Stackoveflow to the rescue!!! This link here shows how to do it.

Finding that answer about splitting a single line of input into multiple lines using just the command line is what motivated me to write this post in the first place. Of course in this case it was useless, but in case you’re wondering, here what I came up with in the end, before realizing that I was doing useless work (first joining multiple lines and then splitting them up again):

ids_list=$(doctl compute droplet list ‘NAME-PATTERN’ | cut -f 1 | tail -n +2 | tr ‘\n’ ‘,’); IFS=’,’ echo “${(@s/,/)ids_list}” | xargs -n1 doctl compute droplet-action reboot

webpack Hot Module Replacement with nginx as reverse proxy

tl;dr: If you’re trying to use webpack HMR from behind an nginx reverse proxy, you’ll need to setup your nginx config to allow web socket connections to the __webpack_hmr endpoint. Look at the end of this article for a nginx server config that demonstrates this.

I was working on a front-end project today using Vue.js (which is awesome by the way!). I started a project using the vue-cli tool with the webpack template. It comes with the Hot Module Replacement (HMR) webpack feature configured.

When I was starting out, I just used the npm development server, which served the site using an Express nodejs app. I save my vue component files and the page reloads the entire app almost immediately. HMR working as expected.

But the project I’m working on also includes a Flask backend API. Once I had done playing around with the front-end app, I started trying to use data from the API in my vue components. As I normally do, I setup an nginx server config (VirtualHost for those used to Apache) so I could use one domain to access both my front-end app and the API. Otherwise I’d have to deal with Cross-Origin Requests. This is also the kind of setup I’ll be running in production, so better to have a similar development environment from the start.

Here’s the server config I had initially. It’s pretty basic, nothing special.

server {
listen 80;
server_name 50mm.dev;
 location /api {
proxy_pass http://127.0.0.1:5000/api;
}
 location / {
proxy_pass http://127.0.0.1:8080;
}
}

I already have dnsmasq setup to resolve all .dev TLD domains to localhost, so I could now access my app using http://500mm.dev and it worked well. Except, HMR seemed to break with this setup. I had to save the vue component files a couple of times and wait a few seconds before I’d see the front-end reload my app. Weird.

A quick Google search didn’t turn up anything useful (I only looked at the first 3 results, so maybe something is there, I’m was just lazy). Next I took a look at the Chrome dev tools network tab, and found a network call for http://50mm.dev/__webpack_hmr that was failing. Hmm, that sounds like something related to HMR. 🙂

It turns out that HMR operates over web sockets, and the proxy_pass I’m using to pass requests to the npm server doesn’t let the socket connect. After a quick Google search, I turned this page on the nginx site talking about web sockets. I edited my nginx server config and had HMR working perfectly. Here’s the final server config:

server {
listen 80;
server_name 50mm.dev;
 location /api {
proxy_pass http://127.0.0.1:5000/api;
}
 location /__webpack_hmr {
proxy_pass http://127.0.0.1:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
}
 location / {
proxy_pass http://127.0.0.1:8080;
}
}

See the /__webpack_hmr section? That’s the one letting the magic of HMR work, allowing the proxying of a web socket connection. I thought it might be useful for someone else as I could’t easily find an answer to my question on Google, and had to do a little bit of diving into what was happening behind the scenes to get this working.

Learning Haskell

I’ve tried multiple times over the past two years to lean Haskell. I always began by starting Lean You a Haskell for Great Good, a programming book with a pretty interesting approach towards teaching Haskell. However, I always seemed to loose my drive and give up; usually somewhere around the end of the first chapter.

This time however, I have miraculously started and kept on reading Real World Haskell. Having gotten through 3 chapters already, I’m really starting to enjoy Haskell. I think it’s one of the most awesome languages I have learned yet. Or maybe it’s just the fact that it’s my first encounter with a functional language, but I still love it!

The biggest thing I’ve done yet; as part of the exercises in given in the book, is to create a program to find the Convex Hull for a set of points using Graham’s Scan. I love the way things are done in Haskell, especially the really small amount of code I had to write to implement this algo. For any one that’s interested,the code is pasted below. A gist is also available with syntax coloring here.

-- GrahamScan.hs
-- Implements Graham's Scan algo to find the convex hull of a group of 2D points
-- http://en.wikipedia.org/wiki/Graham_scan

import GHC.Exts
import Data.List

data Point = Point {
x :: Double,
y :: Double
} deriving (Eq, Show)

data Direction = DLeft | DRight | DStraight deriving (Eq, Show)

comparePoints p1 p2 =
case compare (y p1) (y p2) of
GT -> GT
LT -> LT
EQ -> compare (x p1) (x p2)

sortPointsByCoordinates ps = sortBy comparePoints ps

getAngleOfPointWithXAxis p1 p2
| (x p1) == (x p2) = 1.571
| (y p1) == (y p2) = 0.000
| otherwise =
let theta = atan (((y p2) - (y p1)) / ((x p2) - (x p1)))
in
if theta < 0
then pi + theta
else theta

sortPointsByAngleWithXAxis points = basePoint : sortWith getAngleOfPoint (tail ps)
where
ps = sortPointsByCoordinates points
basePoint = head ps
getAngleOfPoint p = getAngleOfPointWithXAxis basePoint p

getDirectionOfLines p1 p2 p3
| zcord == 0 = DStraight
| zcord > 0 = DLeft
| zcord < 0 = DRight
where zcord = (((x p2) - (x p1)) * ((y p3) - (y p1))) - (((y p2) - (y p1)) * ((x p3) - (x p1)))

-- Main Graham Scan function
_grahamScan [] stack = reverse stack -- Reverse the stack back to a list
_grahamScan points stack =
case direction of
DLeft ->
_grahamScan ps (p:stack)
_ ->
_grahamScan points (tail stack)
where
p = head points
ps = tail points
direction = getDirectionOfLines (head (tail stack)) (head stack) p

-- Entry point for the Graham Scan function
grahamScan points =
let
sortedPoints = sortPointsByAngleWithXAxis points
stack = reverse (take 3 sortedPoints) -- Reverse list so that it acts as a stack
ps = drop 3 sortedPoints
in
(_grahamScan ps stack) ++ [head sortedPoints]

pointsList1 =
[
Point 30 30,
Point 50 60,
Point 60 20,
Point 70 45,
Point 86 39,
Point 112 60,
Point 200 113,
Point 250 50,
Point 300 200,
Point 130 240,
Point 76 150,
Point 47 76,
Point 36 40,
Point 33 35,
Point 30 30
]
pointsList2 =
[
Point 50 60,
Point 60 20,
Point 70 45,
Point 100 70,
Point 125 90,
Point 200 113,
Point 250 140,
Point 180 170,
Point 105 140,
Point 79 140,
Point 60 85,
Point 50 60
]
pointsList3 =
[
Point 60 20,
Point 250 140,
Point 180 170,
Point 79 140,
Point 50 60,
Point 60 20
]

NaNaNaNaNa Batman!

Continuing with my quest to learn graphics and web design, I have completed another Adobe Illustrator tutorial from Tuts+. This one shows you how to create the Batman Dark Knight Logo.

To be honest, I’m actually pretty impressed with how this one turned out. However, I have learned almost nothing with this tutorial. I mean, why the heck did I just add like 6 Fills to a single object? I think this was less about learning stuff and more about just creating cool stuff. I’m down with that too!

So, without further ado, feast your eyes upon my masterpiece!

The Curious Case of django db.reset_queries()

tl;dr: If you have a long running script that uses the django ORM to do db related stuff, and you’re in DEBUG mode, you should know that django saves every query ever run, resulting in your script using more and more memory with every db operation. To fix, either turn off DEBUG mode or just use the below given piece of code after every couple of iterations.

from django import db db.reset_queries()

After a bit more experimentation, it turns out that the best thing to do is to turn debug mode off when using a long running script.

I just found out; the hard way, that if you have DEBUG = True in your django settings file, django will save every query executed. My God!

The reason I never found out before was that if you’re just running the development web-server (python manage.py runserver), django is actually smart enough to clear all saved queries at the end of every http request. But, I was working on a custom management command that adds random data to the db for testing.

I ran the command, telling it to add a 100,000 new objects. But the performance became abysmal after about a 100 or so inserts. At first, I thought it might be because I was using sqlite as the test db. But then I looked at the top output, and the python process was using around 90% of the available memory, and the swap was getting full by the minute.

After a bit of Googling, I found this blog post which taught me about the db.reset_queries() function. After using that, my script ran happily ever after!

Note: The memory consumption still continues to increase with time. Right now, it’s at 72%. But that is after around 30 minutes of execution. Previously, it would shoot up to 90% after around a minute or so. I can’t be bothered to track down why it’s still increasing. Much easier to restart the script every 30 minutes.

Note: I ran my script with DEBUG = False, and it’s memory usage is now fixed at 11.3%. Which means that even for development only long running scripts, you should definitely turn off debug mode.

Moving to Ghost

I have been following the new kid on the blogging block; Ghost, for quite some time now. This weekend, I had nothing to do, so I decided to move my blog here. As well as allowing me to try out Ghost, this also allowed me to test out DigitalOcean, a new VPS service that I’ve been hearing a lot of praise for due to it’s ease of use and the speed with which you can spin up a new machine.

I’m happy that I decided to do this. After spending around 3 hours yesterday night, I have finally setup my blog on my own VPS instance, something I’ve been wanting to do for a long time, and I got the chance to try out Ghost and DigitalOcean. I have to say, I’m impressed by both. DigitalOcean lives up to its promise, allowing creation of new images in under 1 minute, and I got this blog up with Ghost in under an hour, most of which was spent wrestling with my own OCD, wanting to have a pristine blog server with no extra software or unnecessary configurations. This meant that I created and destroyed the server at least twice.

My plan now is to migrate my old blog from Tumblr to here. But I’m guessing that doing that will take longer than a couple of hours. So I’ll be getting to it next weekend. Until then, bye!

Update: I’ve moved all my old blog posts from Tumblr to here. Didn’t take that long either. Copy stuff from the old blog and just paste it here, set the date and publish! Thankfully, I had long ago decided to write on my Tumblr blog in Markdown as well, so I didn’t really have any issues in transitioning the olds posts to here. Go standards!

import(‘artistic ability’)

Well hello there. It’s been a long time since I last wrote anything here, so here goes. I have, since a long time wanted to learn design and other artistic stuff. Well, after I moved to Dubai to work with Dubizzle, I had the opportunity to; for the first time, see how real designers worked, and to be friends with them. So, I saw my chance to learn stuff from some of the greatest designers that I personally knew, and here I am.

I asked a designer friend of mine where to start, given that the best thing I can draw on paper is a tree with two strokes for the trunk and a whole lot of cloud like leaves. Which is something most 1st graders can do. Yes, I have the artistic ability of a 7 year old. What he told me was that to draw on a computer, you don’t need much sketching experience or whatever. Then he told me about a friend of his who can’t draw on paper, but can create these awesome illustrations on Adobe Illustrator. I’m not sure if he was telling the truth about this other guy or was just trying to motivate me, but it worked.

I bought the Adobe CC subscription after a few days, and started toying with the idea of drawing something. Well, after about a month, I finally started yesterday, with this Tuts+ tutorial, and today, I have completed my first illustration ever. YAY

And here is my masterpiece. I’m sure than in a 100 years, it’ll be as appreciated as anything from Picaso is today.

Hopefully, I’ll continue down this path and will be posting more stuff regularly.

Run Vim Macros on Selected Lines

Short Version: to run a vim macro over selected lines (in visual mode), run the following:

:'<,'>normal @q

It’s been a long time since I last had anything to post, and since I just recently discovered a new vim trick (there is an uncountable number of them) I decided that it’s time to learn markdown again and start writing.

I’m pretty sure that if you’re a programmer, you use vim (if not, I don’t like you… :P). Even if you don’t use it, you’d have to be living under a rock on a deserted island on some long forgotten planet not to have heard of it; the one editor to rule them all!

So, like most text editors, vim allows you to record powerful macros. In fact, almost anything that you can do in vim can be recorded as a macro (correct me if I’m wrong here, I’ve just started using vim a couple of months ago).

For example, I’m currently working on a django project at work and I recently had to code the signup view for the site. What I needed was something like this:

def signup(request): if request.method == 'POST': form = SignupForm(request.POST) if form.is_valid(): user_params = {} user_params['username'] = form.cleaned_data['username'] user_params['email'] = form.cleaned_data['email'] *snip* user = User(**user_params)

now, recording a macro to convert a list of params like this:

username, email, last_name, first_name, country

into this:

user_params['username'] = form.cleaned_data['username'] *snip* user_params['country'] = form.cleaned_data['country']

is simple. The trick I learned was running this macro on a selection, since otherwise I would have to manually count the number of times the macro needs to be run. Simply, use Shift-v to go into visual line select mode and select the lines on which you want to run your macro and type the following command:

:'<,'>normal @q

where q is the name of the macro you recorded earlier. And that’s it!

As a side note, Stackoveflow is AWESOME! I got this trick from a SO Question as well.

jQuery is Awesome

Do you know how awesome jQuery really is? If you’re still here, I have a feeling you want to find out. Here is a simple sample from one of my freelancing projects that got me thinking about the power of jQuery, and how it has changed JavaScript programming.

The interface is very simple, but the thing I want to show you is the show/hide control. It’s those little [+/-] things at the top of each element group. The effect is quite basic, but to implement it in JavaScript will require a lot of code. I can’t say exactly how much, but you’ll have to take my word that it’s a lot. 🙂 And that’s a lot of code just to get the page up and running without worrying about the browser compatibility issues (thinking of Internet Explorer).

Using jQuery, the entire JavaScript code to get that page up and running in almost every modern browser; including IE, is:

$(function() { $('.toggle_display a').click(function(event) { $(this).parents('.header').siblings().stop(true, true).slideToggle(); event.preventDefault(); }); });

Using Coffee Script (which is awesome enough to get a post of its own), the code becomes:

$ -> $('.toggle_display a').click (event) -> $(this).parents('.header').siblings().stop(true, true).slideToggle() event.preventDefault()