Rahul gives unsolicited advice

At work, I am part of a team which maintains the Enthought Tool Suite (ETS). ETS includes a number of open source Python packages which are the foundation of the desktop applications we build at work. One of those packages is enable , a 2D drawing library. Yesterday, I came across this issue on enable regarding a python module ( kiva.fonttools.sstruct ) which wasn't used anywhere in the enable codebase at the moment. "... at the moment" is important here because the enable GitHub repository has been evolving for over 10 years now and we don't know if at some point in the past, kiva.fonttools.sstruct was used somewhere in enable. Before we decide on removing the python module from the codebase, we need to understand when it was added, who was using it and how and when the dependency on enable.fonttools.struct got removed from enable. Only then can we confidently remove the module without worrying about unexpected repurcussions. So, I started digging. The first thing ...

Software developers or open source software (OSS) contributors that use GitHub to manage their projects probably use one of two git workflows : fork master branch, i.e main repository, to create a personal copy of the project --> clone fork to local workstation --> create a new local branch from fork --> make relevant changes on local branch --> commit changes to local branch --> push local branch to origin, i.e your forked copy on GitHub  --> submit a pull request (PR), clone master branch, i.e main repository to create a personal copy of the project --> create a new local branch from master --> make relevant changes on local branch --> commit changes to local branch --> push branch to origin --> submit a PR. Which of these two workflows the developers follow depends on many things. And now that I've introduced you to the basic workflow and the premise as to why/how I ran into a problem, I can tell you about the problem and the soluti...

If you're working for a company/team that develops a product that can be used on Windows, OS X and Linux, then you will have to test the changes you make on all three platforms to see if things are working the way you intend them to. I presume that you're using version control, I personally use git, to manage the code base for the project. Say you make changes to the code base on an OSX machine and everything looks fine so you push the changes to a branch. Now, you will want to look at the changes on a different OS to make sure that the changes are behaving well, which you can do using 1 git checkout --track <remote>/<branch-name> I hope you're familiar with   git checkout,  which can be used to change to a different working branch or it can be used to remove changes made on a file on the current branch. The additional --track argument tells git to create a new branch from a remote branch, where the remote is usually set as origin. You're prob...

The CIA Waterboarded the Wrong Man 83 Times in 1 Month  : In the name of the war on terror, the American government seems to have carried out operations that violate human rights and numerous international laws. This is one such account of a man tortured, maybe even for the sake of learning how effective the methods of torture were, and not coincidentally, the man was trained by the CIA to fight against the Russians, the very agency that tortured him a decade later. Being A Developer After 40  : Now that I'm on the path to becoming a software developer, I'm taking such articles seriously. This is an account of a software developer who has over 15 years of experience in the industry and who has seen one fad after another pass. A question that every software developer has to address at some point or the other is whether or not they are programming in the right language, whether or not they are moving forward, with respect to the community and what not. And this guy has prett...

As I mentioned in my previous post, working at Enthought involves a lot of forking, commiting, pushing and merging. Git is used for code version control and while I was comfortable working with git earlier, I had to learn a lot of new tricks. One of the first things I had to learn was branching and PRs, as I had mentioned in the previous post. A note of caution here. Say you're working on adding features to a stable code. In order to add the features and check them, you create a branch called 'features' using git checkout -b features Now say, in the middle of this process, you've been asked to fix couple of bugs in the supposedly stable code. To code and submit the fixes, you need to work in a different branch, say 'fix', created using git checkout -b fix Here's the catch. You need to create the branch from master/stable and not the features branch you were previous on. So you will have to run the second command after running git checkout mas...