I’m a bitch when it comes to settling down on things, I admit. Two of the things that have bugged me the most for the past several years are font family and syntax highlighting. I can vividly remember the countless hours of torment trying to find the “perfect” font when I used to work on Windows (PT Serif and Georgia came close), and fiddling with syntax highlighting of code when I came to Linux (don’t even get me started about font rendering on Windows).
Should string be deep red, as they are in Kate, or is the pro-PHP blue better? Or maybe green, like some Python scripts online show? Should variables be blue, royal blue, deep blue, electric blue, dull blue? Bold? On and on and on, until I thought I’d go mad.
And then a simple thought struck me: why not give up color altogether?
The result is this, which is how every editor I own these days looks like:
Is this the answer to my prayers? Time will tell, but for now I’m experiencing indescribable relief.
A common tendency on my part, when it comes to screening free apps for download, is to look at ratings (of course) and the number of downloads. Just take a look at any of the category leaders, and numbers like 5 million are not unheard of. However, I can’t help thinking of a caveat.
I grant that I’m an outlier when it comes to a modern consumer, but a typical app that I like and use has seen multiple removals and installs on my mobile phone — typically like 10 or 20 times at least. And then we have updates to think of. Is an update equivalent to a removal and reinstall (why else do we have to download the full app even for “bug fixes”?)?
I think I wouldn’t be wrong in arguing that very roughly speaking, we can take one tenth of the advertised figure as the true number.
It’s past 4 AM and I’m brimming with joy! The day’s effort I put into learning Python has paid off in terms of a very useful script (for me, at least!). I often need a quick and dirty way to resize images but the GIMP GUI takes forever to load. So I wrote the following in Python using the PIL image manipulation library. It’s quite limited, I know, but it works sweetly!
# Simple script to quickly resize images from command line
Author: Ankush Thakur
Created: 15 February 2015
Input: Filename followed by desired width
Behavior: The image will be scaled proportionately
import os, sys
from PIL import Image
if len(sys.argv) != 3:
print("Wrong usage. I need [filename] [width].")
filename = sys.argv
final_width = int(sys.argv)
im = Image.open(filename)
initial_width, initial_height = im.size
if final_width > initial_width:
print('Sorry, can\'t make images bigger.')
# calculate height
final_height = (final_width * initial_height)/initial_width
# create thumbnail
print("Failed to resize " + filename)
Am I cool or what?! B-)
Every profession has its challenges, and programming is no exception. There are times when we all feel lost and defeated, not to mention disgusted at our sheer lack of skill.
Well, there’s nothing wrong with you. If you’re feeling the blues right now, it’s only because you are missing a realignment of your inner compass. To help the process, I’ve put together this document that I believe every programmer should print and meditate upon at least once a week.
I call it The Programmer’s Manifesto. Feel free to use it any way you like, even passing it on as your creation.
If it helps you, please leave a note of thanks; it will make my day!
I used to think that PHP bashing was nothing more than a fashionable trend among developers, until I got caught in the mess myself. I’m yet to declare it a horrible language (although I’m beginning to award it the “hopeless” label), but my trips to PHP hell have started.
Anyway, what I want to share today is the existence of two helpful ways (call them Good Samaritans, if you will) that can help beginning PHP programmers move beyond cursing their scripts and getting to know exactly what went wrong.
The first is to set the display of all errors on. You can do this by writing these two lines inside your script:
This will show you even the minor notices, which are frequently useful in debugging a program.
But what if PHP itself crashes? It so happened to me once that my script was running over the 30-seconds time limit. The script would just drop and there’d be no output. What the heck was going on?
Enter server logs, your second friend. I was able to figure out which line was causing the infinite loop by using the following command as root (I’m assuming you are on Ubuntu and Apache2):
tail -1 /var/log/apache2/error.log
With the sore spot located, I was able to immediately rectify the problem and move on. Hope it helps someone some day!
I wrote earlier about how happy I was on finding Flask as a web development tool for Python. Well, I was wrong. I’ve finally got Django to work.
Goodbye, Flask. :'(
After spending more than three hours running around in circles and jumping through hoops trying to set up Apache server to run Python scripts, I finally discovered the super-elegant Flask framework. Since setting up mod_python or even wsgi wa such a pain in the backside, why not try a framework, I thought. One step led to another, and before I knew it, I had my script running!
Very different from how PHP runs, but now that I’ve figured it out, it looks quite intuitive. And the framework? Ah, don’t even get me started on its never-ending awesomeness. Routing, which makes a mesh of your brains in most PHP frameworks, is so easy here that I could make a living out of teaching it to sheep. Honestly, Flask is incredibly beautiful and incredibly close to the programming philosophy of Python. Now I know I’ll be rewarded for sticking by this elegant, elegant language.
I will have a good night’s sleep!
I wrote earlier about my dilemma about Python. A very neat language that’s slower than Java and is hampered by the GIL? Well, I’m happy to announce that I’ve been able to lay my doubts to rest and welcome this breeze of relief called Python.
Just last day I was struggling with something in jQuery and I thought I’d put the solution here. I have a table in which some rows are given. The last two cells of each row are icons for editing and deleting the row, like so:
The selected row can be saved into a variable like this:
row = $(this).closest('tr');
The cells can then be accessed by this method:
var date = $(':eq(0)', row).text();
var in_time = $(':eq(1)', row).text();
var out_time = $(':eq(2)', row).text();
var value = $(':eq(3)', row).text();
var type = $(':eq(4)', row).text();
var comments = $(':eq(5)', row).text();
Once we are done editing, the values can be saved back like this:
The original problem was that I was using “:nth-child(1)” to access the cells, which was replacing the <img> tag with date from the first cell. As a gentleman on StackOverflow pointed out at that time, the right approach would’ve been to explicitly target <td> only:
I grew up believing that one day I’ll build my career around “good” languages such as Python. After all, the language is super-clean, the community is vibrant, and the books written on it are a delight. But these days I’ve been severely put off by the Global Interpreter Lock. No concurrency? You must be kidding me! It’s very likely that I’m getting blindsided by a once-in-a-blue-moon scenario; I don’t understand concurrency and I’m not sure when I’ll need it.
And yet, this is how human emotions work. I might go back to Python, but I feel cheated. Why, oh why, did my absolutely most favorite language have to have this horrible defect?
Can I still bring myself to love you, Python? Time will tell.