RSS

Author Archives: Mete

Mintty Weirdness

I use Cygwin to emulate a Unix-like terminal on Windows. Even though Cygwin is pretty good in emulating Unix terminal, its UI leaves a lot to be desired for, so I decided to use Mintty on top of Cygwin. Mintty not only looks nicer than Cygwin but it also has some useful features like easy copy/paste, drop & drop of text files and so on.

I installed Mintty through the usual Cygwin package installation process and I saw that it put mintty.exe file under cygwin’s bin folder. When I tried to run Mintty by invoking mintty.exe from Cygwin, it worked fine. Pretty soon, I was changing the terminal properties and making Mintty look like I wanted. So far so good.

The problem started when I created a shortcut to launch Mintty from Windows Start page. I wanted this shortcut to launch Mintty on Cygwin by default. When I clicked on the shortcut, none of the normal Unix commands would work, I would get a “command not found” error from bash. After Googling for a while and some random experiments, I found out that I had to go to shortcut’s properties and change its target to add a dash at the end. So my shortcut’s target is “C:\cygwin64\bin\mintty.exe -”

Don’t know or care why I have to do this but I wish developers put more thought in the first time use experience of their applications/libraries/packages.

 
Leave a comment

Posted by on August 13, 2013 in UNIX, Windows

 

NodeUnit Debugging

In my previous post, I talked about debugging Node.js applications. We use nodeunit to unit test our Node.js scripts and it’s useful to be able to debug those nodeunit tests as well.

So how do you do that? It’s quite simple. You follow the instructions in my previous post except instead of pointing the debugger to a Node.js script, you point to your nodeunit instance and then you point to your test.

For example, if nodeunit is installed under node_modules and your test is under test folder, here’s how you’d debug that using node-inspector:

node --debug-brk node_modules/nodeunit/bin/nodeunit test/myDummyTest.t.js
 
Leave a comment

Posted by on July 22, 2013 in Node.js

 

Node.js debugging

In my current role at Skype, we do lots of prototyping to try out different ideas for various problems. We’ve been using Node.js heavily as it allows us to quickly iterate on different server architectures. Even though I’m not a big fan of JavaScript as a language (Why?), I do like Node.js as a prototyping platform. Once you get used to the callback mindset that comes with Node.js, you have pretty much everything you need to write some serious server side code.

In this post, I want to outline how to debug Node.js applications. I tried a few different debug tools for Node.js but I found node-inspector to be a decent tool to debug Node.js applications.

First, install node-inspector:

npm install -g node-inspector

Start your Node.js application with –debug-brk which tells the debugger to pause your script on the first line:

node --debug-brk yourNodeApp.js

Start node-inspector

node-inspector &

Go to http://127.0.0.1:8080?debug=port=5858. Last time I tried, IE did not work, so try with a non-IE browser.

At this point, you should see your Node.js script stopped on the first line. Click on scripts tab to see all your scripts and set breakpoints where ever you want and then step through your code like you normally would.

 
1 Comment

Posted by on July 15, 2013 in Node.js

 

Long time and new beginnings at Skype

London Eye

London Eye

I can’t believe it’s been more than 8 months since I last posted. It’s been hectic both personally and professionally but that’s no excuse as life is always hectic and I hope to get back into the habit of posting more often. There’s a lot to share.

Lots have changed since last time I posted but the biggest change is that I decided to leave Adobe after 6.5 years. I had a wonderful time at Adobe but I felt like it was time to try something new so I accepted a new role at Skype. I always loved and relied on Skype for communicating with family, friends, and more recently with co-workers in the US and Switzerland when I was working remotely from Cyprus and I thought it’d be cool to be part of such a positive brand and work on something that millions of people use every day. I started working for Skype on April 15 as a Senior Software Development Engineer in London.

If you didn’t know, Skype is part of Microsoft now and as a Mac and Java guy, it’s been quite an experience to switch to Microsoft land. I plan to share my experiences on switching from Java to C# from Eclipse to Visual Studio from Amazon Web Services to Windows Azure from Android to Windows Phone :-)

At Skype, I’m part of a group split between London and Palo Alto and we do technology research and incubation. The coolest part of my new role is that I get to play with different programming languages, frameworks, technologies and I’m no longer constrained to just Java. This means that I’ll be able to share with my followers on more diverse technologies like Node.js, .NET/C#, Azure, etc.

 
3 Comments

Posted by on June 30, 2013 in Uncategorized

 

Thoughts on code style

I recently had a nice discussion with a fellow programmer about code style which triggered me to think on this topic and that in turn triggered this post where I hope to outline my thoughts on code style.

Code style is a set of rules used when writing source code. These rules do not usually make any difference to how the code runs but they make a huge difference in how the code looks like. In virtually all software teams I was part of, code style caused some arguments among programmers at one point or another. It is a controversial topic. I think there are two reasons for this.

First, programmers are very particular about how they do things, especially in writing programs. If you dare to ask a programmer to write his code in a certain style, you better have a really good reason for it.

Second, programmers tend to have strong opinions on topics that they understand inside out. If a topic is hard to understand, there has to be an initial upfront investment to understand the topic in order to have an opinion about it. The investment has to be even higher if you want to have a strong opinion because you’ll need to defend your strong opinion against fellow programmers and that requires that you really know what you’re talking about. Code style is both trivial to understand and requires minimal investment in understanding the code style rules. Therefore, programmers tend to have strong opinions about it.

The first camp in code style thinks that code style is extremely important in programming. Code style in programming is like punctuation in writing. No serious writer even considers writing without punctuation and as such, no serious programmer should consider writing code without a common style. According to this camp, the team has to agree on every little detail in code style and the whole team has to adhere to those rules. It’s a sin to not adhere to code style. You write code not for yourself but for other programmers to read and understand and you have a responsibility to make sure your code is understandable and adheres to some common style.

The second camp in code style thinks that code style is utterly useless and sometimes even harmful in programming. They think that it’s hard to find a common code style that all programmers agree and it’s even harder to make programmers adhere to it. At the end of the day, code style has no effect on how a program runs, so spending so much time and effort on something that does not make a difference in reality is useless. Instead, time could be better spent with test coverage or design improvements which do have significant impact on how a program runs. Code style not only causes friction in a team, it also takes valuable time away from useful activities like extending test coverage.

I think both camps have valid points and I can relate to both. However, I don’t think that either camp is totally right. The right attitude about code style lies somewhere in the middle. The first camp is right that we write code for others to read and I agree that we need to pay attention to how we write code. It’s just selfish to have a “my-way or highway” type attitude with code. There’s something more important about code style though. If a team agrees on a common set of rules regarding code style and actually sticks to those rules, it shows that the team is indeed a team that can act like a unit. It shows that people have no egos and the code generated is not considered as yours or mine but rather considered as team’s code both for the team members and to the outside world. This is an important goal to strive for a team and since code style helps in achieving that unity, it should not be dismissed so easily.

On the other hand, the second camp is right that code style should not come at the expense of test coverage or other activities involved in software development. I think this could happen if the team suddenly decides to implement code styles on existing/legacy code. Instead of fixing the code and making it better for existing customers, the team spends the time to make the code look pretty. That’s silly. Similarly, in dysfunctional teams, agreeing on a common code style is a daunting task and it could suck a lot of time and energy out of the team. All of this can be avoided by having a strong figure in the team leading the team to agree on a common code style upfront, however little the commonality might be, and then making sure everyone sticks to these rules throughout the project. Sure that’s some initial investment but once the initial agreement is done and habits start setting in, programmers don’t really have to think about code style, it just happens.

To sum up, I believe that code style is important and all its pros and cons should be considered before adapting or completely abandoning it.

 
Leave a comment

Posted by on October 19, 2012 in Programming

 
 
%d bloggers like this: