One more reason to cherish the time we live in

May 2, 2016 Leave a comment

I have been at the consuming end of so much art for so long now I should start putting out something ­čÖé
Well, I do not have the intention of becoming an artist, but the prettiest words and sentences I could come up with, I would use to thank Skunk Anansie for their art and creative work ­čÖé

I mean it! Skin’s voice is amazing. Her performance alongside Pavarotti of their “You’ll Follow me Down” is incredible. No one song of theirs is such that I’d not want to hear again. More accurately, I have listened each and every one of their songs multiple times because I like them… because the first time I listened one of their songs, just to check it out, I liked it a lot. And their work is unique. I haven’t yet heard anything that sounds anything like them. Given the amount of creative work produced in our time, one would think that there must be someone whose work resembles that of Skunk Anansie, but, nope, never seen yet. They are great!

I wrote that yesterday, and today I was watching Skunk Anansie’s Charlie Big Potato video. Some commenter there suggested that the video is very similar to that of Prodigy (another group that I like a lot) for their song Breath. Well, I have watched both videos multiple times and never noticed the similarities, but now that others pointed it out, I see that there actually is some similarity… I guess this just goes to show how cool the two songs are that they just shut down that part of my brain that should notice the similarities, hahaha. Or, perhaps, how forgiving we tend to be of inconsistencies in our judgement when we are judging something or someone we like a lot.

Categories: Uncategorized

How small the world is getting

May 1, 2016 Leave a comment

I have read the Psychopath Code by Pieter Hintjens.

Before I proceed, I would like to pay tribute to the living man Pieter Hintjens, whose work can be found in hintjens.com.

Pieter is, primarily, a software engineer. The guy has survived cancer five years ago. The disease has returned, and Pieter, after considering everything (his cancer has metastasised), has made his mind up: he will perform euthanasia, in due time… and talked about it in his last (as in his final as well as most recent) post in his blog. You can go read it. If that is not enough to spark respect and some interest for him, then know that he writes books and makes them available in various schemes, including free pdf copies.

Back to the book. I have to remind you, the guy is not a psychiatric professional (there is a disclaimer in his book). But, for whatever reason (mentions personal experience), he decided to write a book on psychopathy. In a reddit thread, his ability to write a book on such a sensitive and difficult topic is severely questioned. Luckily, I read the book first and the thread second. I could not stop reading the book, and I had a hard time to give much time the reddit thread. The thread mostly discusses him – his authority to write a book on psychopathy. The book, I actually liked and found it, at the least, intriguing. But it was growth inducing as it gave me a new perspective.

Early on in the book, Pieter says: “I wanted to explore psychopathy-as-an-adaptation”. I know that the approach is not newly introduced to the world in this book, but it was new for me. And, this line alone makes the book a whole lot valuable for me. I’d say that this is a perspective that I’m better off knowing. I appreciate this line in two contexts: 1. environment may induce predatory behaviour. If that is so, then we may reduce destructive behaviour by correcting the environment. Actually, gives me hope that individuals may be saved from the vice of predatory behaviour with proper behavioural therapy – making them aware of the effect of the environment on their behaviour. Not my call to make though, given my professional background is not psychiatry. And, 2. once the kind of environment that is prone to encourage predatory behaviour is identified, an individual is better able to stay ahead of destructive individuals and cope with the effect of interacting with them, should one find themselves in such an environment. And even better, one would be better able to chose the kind of environment to avoid.

Now… Yes, I do recommend the book. It is a great book. It is the reason I will read Pieter’s other work not related to the C programming language. But, I also have some criticism.

Rationalization – when one tries to retrofit the past events to a logical explanation. I think this also is a very likely fallacy when one tries to give a detailed explanation of how emotions follow one another. In the later parts of this book, Pieter ventures to do exactly this. That is all good and dandy, and may fit many people’s experience. But, I think that, strictly speaking, this is quite shaky. The mapping of emotions to the names we use for them may be quite unstable. Rationalization, as a logical fallacy, is bound to happen when one tries to do such a classification of such vague concepts as emotions. I am not saying that the fallacy has been done, or that it has not been done… as a matter of fact, there are so many pieces and interrelations identified there that I’d not claim to have identified the fallacy given that I only read the book once. But, that is as much as I can examine for criticism on the book.

Finally, I liked the book. I am now reading his Culture and Empire. I am also reading his blog posts. There is advice he has to share with software engineers. He also has a book on a piece of software (a messaging system that he has built, 0MQ) that can come in handy in your project as a software developer when working in distributed systems. I think he has lived a productive life. I respect that.

Categories: Uncategorized

Tools developers use at their job

January 20, 2016 Leave a comment

As mentioned in my earlier post, I am in the process of reflecting on my experience as a Java Developer. This time around, I compiled a list of tools I have used in my job.

  • Programming language, Java. A programming language┬áis the first tool we learn when starting the career of a Software Developer. We need a way to interact with machines. Enough said, no?
  • Issue tracking, Jira. This is a tool that allows developers keep track of what they are working on. It allows users to describe a task, add comments to it, keep track of who is working on what, give approximate estimations about the time it will take to be finished (though this feature is rarely used because it does not work).
  • Source code version control, GIT, Mercurial, SVN. You will inevitably work in a team. That means, you will need to share code with others. This is where this tool comes in handy. However, even if you work alone on something, using one alternative of this tool is helpful. It will remember for you all versions of your files. (SVN is a legacy tool, GIT is my favorite though it is very similar to Mercurial. Also, GIT documentation is really cool.)
  • Build tools, Ant, Maven, Gradle. Ant is the oldest, and Gradle is a spaceship. Maven is very powerful and yet has a low barrier to entry. It manages your project’s dependencies (downloads jar files, puts them in a standard location in your operating system, and includes them in the build path of your project. Ain’t that cool?) Then, it can compile your code, run tests, and build output files (jar, war). It does more, ┬ábut this is what I used Maven for.
  • Integrated Development Environments, Eclipse, IntelliJ. Yes, you write code in your IDE. It has an editor and it’s own compiler which aids in giving you visual clues regarding any compile time error and eventual warnings. However, there is much more to an┬áIDE than this. It usually includes a debugger, key shortcuts to various tasks, various views for when you are doing various tasks. It will also have plugins for your other tools like build tools and source code revision systems, so you can use them from within your IDE [right-click, get thing done, without switching your windows].
  • GREP. This is a Linux tool. It is highly unlikely to be used in development environment. But on deployment environments it comes in handy to filter text of interest in log files and such tasks. It pays dividends to be able to use it. One needs to get familiar well with what it can do, and then using its man page or online resources one will be able to use it well.
  • Less. This too is a Linux tool that you use to inspect the content of a file. It has search and navigation shortcuts. It is frequently used for viewing log files on deployment environments.
  • Vim. This is a Linux editor. One would use this when modifying a file on a remote Linux system. Something like changing a configuration value.
  • SSH clients, putty. One uses this to connect to a remote host. This is something you are more likely to learn after you start working and join a team. But I am putting it here just for the sake of completeness.
  • SoapUI. This is a tool for interacting with web services. It basically allows you to see the xml messages you receive from a SOAP based web service. When testing a REST web service that responds in json, you will see just that. It is a cool tool, with a lot of features. Basically, you use SoapUI to test your web services.
  • Research, forums and stackoverflow. Yes, these are a developer’s frequent go to friends. Getting info and advise online is mandatory. However, one MUST be able to evaluate what is good advise and what is not when advised online.
  • Continuous integration, Jenkins, Travis. Jenkins is cool. It is highly configurable and very generous with the information it makes available. Using this tool is often assigned to a quality assurance person, but in smaller teams, this is taken care of by developers. And Travis is anther CI tool. It does the same job and is highly popular amongst open source projects.

That’s it. This is the tools I remember having used in my role as a Java Developer. Right when I started this article, I noticed that there is in Quora a question about what tools developers use. That gives me heightened confidence that this article may be useful for someone.

Categories: Uncategorized

What developers do

December 5, 2015 Leave a comment

I have already worked as a paid Software Developer for three years now. I am neither a complete noob nor a senior developer, whatever that may mean [different people have different ideas of what that is]. However, I want to list here every kind of task I have done as a developer and also what I saw my colleagues do as part of their work. I expect this to help other software developers with less experience to get a clearer idea of what they need to get used to. This will also allow me to consult my memory for what skills I need to improve on.

1. I have written lots of code. Obvious, no?! I introduced new classes, new methods to existing classes, and I also removed code. You do this even if you do not have any experience as a paid developer. Writing code is the least of what developers do, not the most. And it is very irresponsible to behave assuming that writing code is all one needs to do.
2. I have read lots of code. I have read code that other people have written so that I can determine what part to change so that I can best implement a bug fix or a new feature. Reading code that you are not familiar with is a very difficult task. It can push one’s patience to the limit. It is always best to ask someone that is familiar with the code to help you understand the code that is new to you and is not easy to understand. One time when I was talking to a friend who was invited to join a start-up cited “getting familiar with a new code base” as the reason he was┬áreluctant to join. It is that important to get ready for this.
3. I wrote unit tests. For the less experienced, this is a better way to do that which you do by writing a main method in Java to try your code. However, in the industry, instead of using main methods, we use unit tests. This has the extra benefit because your unit test code documents what your actual code is supposed to do. And, as long as your tests pass, you do have some confidence that the actual code is all fine and no one changed it. At the least, writing unit tests means that there has been more cognitive effort put to understand and write the code. Some people make really good cases of why unit tests are good, and I am a fan of unit testing. But, there is the possibility that someone did change the code, they also changed the unit tests to adjust to the new code, and effectively may be hiding bugs. This may lead to the question: do we need extra unit tests to test the unit tests that test the actual code? But that is a mean discussion. At some point, we need to trust each other’s ability to make the right calls, and with unit tests in place, this point is closer to what a balanced level of trust-skepticism is.
4. I used lots of tools. I have used programming languages, application frameworks, integrated development environments, build tools, source code version control tools, stubs (like fake email servers), Linux tools like grep, pagers, and navigation, code review tools, continuous integration tools, issue tracking, and perhaps more. Now, Java has around 50 key words. It is not too difficult to memorize the keywords, but there are subtleties to some of the keywords and significant consequences to using them. One can never be sure that they know their language. It takes time and experience. But I cannot stress enough the importance of knowing your tools, especially your IDE. I do not have hard data, but I think that most of a developers cognitive workload is done staring at the IDE. And if you are capable of using your IDE’s shortcuts, you can afford more cognitive resources to your actual tasks. Particularly when you are working on an existing code base that you need to get familiar with, which will also be the more likely case. Also, your ability to use your source code version control tool makes you a better team player. It is not too difficult to learn it and the benefit is significant. Know your tools, know your tools, know your tools. That means you will know your team’s tools and you will be helpful to others, too.
5. I had to debug. Debuggers are very powerful tools. At school, I used System.out.println(); to debug. I did the same in my first job. It led to crazy laughs. But sysouts are not the right way. You will inevitably forget removing the sysouts and it can be irritating for others in your team. Plus, your productivity benefits from your ability to utilize debuggers, which is a huge plus.
6. I talked a lot. I frequently had to express beforehand what I intend to do, some times had been intending to do (say for example when someone was reviewing my code). Your ability to communicate effectively is mandatory. You will often have to visualize your ideas by drawing on a board. Sometimes, you might even need to touch the screen and say “this exact part of the code is where I expect the execution to go through and do so and so” [and then add, “but┬áI do not know why it is going through this other part” ­čśŽ ].
7. I had to listen. Just as I talked, others talked, too, and that means I had to listen. Now, it is your interlocutor’s responsibility to be clear, but, you are better off if you understand even when your interlocutor may be less than clear. If you are well familiar with the business domain of your application and with the code, you are more likely to understand others even when their ability to communicate is less than perfect.
8. I spoke English. It is important to note that of the three years that I worked as a professional Java Developer, for two different employers, the client and management have always been foreigners, so we interacted in English. It is mandatory that one is able to speak English if one is to be able to serve in this industry. The small-market needs are already well met with ready-to-use code bases that need minor tweaking. If you are to serve as a developer, you need to operate in greater markets where automation of non-trivial tasks is the need. That means, you need to be able to serve globally.
9. I had to learn. Learning is part of every one of the points above. I had to learn to code, to use my IDE, to learn the new code, the business domain of the code, to learn English. Technology changes, it is inevitable that you will have to learn. Be ready for this. That means, point 8 is a must because most sources of knowledge in this field are in English.
10. Document. It may not always be your job to maintain documentation, but it is good to do. You might need to document the application’s architecture, sometimes you might need to write a comment for the code, though it is best without it. And sometimes you might need to document the behavior of the application. For example, you might need to describe what parameters some part of your application’s API expects and what the response actually means. Simply, you need to document how to best use your application, whether programatically or manually [I thought “programatically” is an English word, but I am having a spellchecker complaint here].
11. I used database clients. It is a must that you are able to interact with your database outside of your application. Knowing how to use a decent database client is a life savior. And it is not so complicated to use one. This also means that you’d need to be able to write SQL.

There you go! I did not plan it to be eleven points but it turned out that I could recall eleven activities in my job as a Java Developer. And, let me assure you that writing code is not the most of what a developer does.

Categories: Uncategorized

How I got 35 dollars today

February 23, 2012 Leave a comment

Today in the morning, I was studying as I have an exam on Saturday. In a short break skimming my facebook wall, I noticed that blidr posted a logical challenge offering 35 bucks to the one that solves it.

The challenge may be viewed here

I solved it and emailed Adam (bildr’s admin, I guess) with the solution, and he then gave me 35 dollars in a gift certificate in sparkfun.

I guess, you could like bildr’s page on facebook for a chance to participate in other challenges bildr posts.

Anyways, it was very generous from Adam and bildr, and I thank them for the certificate. I laid my eyes on some books in sparkfun that I would want to have, but due to high shipping costs, I will have to add money to the certificate I was given so that I can purchase the books.

Briefly, sparkfun sells electronic pieces and books that one can use to build small, or maybe bigger (I do not know), projects. bildr on the other hand helps with information on how to build things. Anyways, that is brief. If you feel like a hacker, then you should check for yourself what sparkfun and bildr do.

P.S. The solution may be viewed here.

Categories: Uncategorized

Apache won’t start and IIS is the problem

February 15, 2012 Leave a comment

Alright. For studying purposes, I have IIS installed on my computer. For work, I need xampp installed.

I have been trying a couple of days to change the port Apache listens on. There is not much difficulty in changing 80 to some other number on lines 46 and 176 in httpd.conf in …/xampp/apache/conf However, Apache would refuse to start even after that. After a few futile attempts to change Apache port, I decided I’d try changing IIS port.

Control Panel, Administrative Tools, Internet Information Services opens a Window. This window has two panes, the left and the right. On the left, select Web Sites. You will see on the right Default Web Site and information whether it is running. If it is, just stop it. Once you stop it, go start Apache in your xampp control panel. This should start Apache. However, if you want to access Apache index page, make sure you add the port it listens on if you have changed it in your httpd.conf file.

Basically, at least in my machine, I have to start Apache while IIS is not running. If IIS is running, seems like it won’t allow Apache to start even if the port Apache listens on is different from the port IIS listens on.

Also, even if you change the port Apache listens on, when you start it on your xampp control panel, what you’ll see is ‘Apache started [Port 80]’

There is a XAMPP.C file inside your xampp folder (you’ll need to navigate to find it in src folder). On line 236 of this file, 80 seems to be hard coded. I assume that changing that line and compiling the file would allow one to change what xampp control panel shows.

Anyways. I just thought I’d put this in my blog for someone who might need help, as well as for my eventual reference in the future.

Categories: Uncategorized

random post

August 11, 2011 Leave a comment

It’s been a while since my last post. I have checked this site quite often for visitor stats and such, and I have also produced much I would love to talk about, but haven’t had the time needed.

Since I am going to have a ten-day period of less pressure, I thought I could just put off my sleeping for five minutes tonight and come back to blogging.

These past three months have been quite dynamic. I had final exams, started working as a programer (although I have been learning more than coding anything significant), and even had a one-week vacation.

As far as coding goes, I have built a small app for genealogy that lets a user to enter family members’ info such as first and last name, birth date, profession, and such as well as some crucial info to make dynamic family tree generation possible. This I did using PHP.

Another, one page, but nice app I coded is one that lets a user pick dimensions of two matrices, and if the matrices happen to be addable, the application lets the user put in the matrices’ values and calculates the resulting matrix. I do not think many people have difficulties with adding matrices, but this is the first step towards building an app that visualizes the process for multiplying matrices, which I do think someone would find helpful. This, too, was written in PHP.

Anyways, I will work on my code, and make it better, before I post it and let everyone use it, if they desire to.

This time, this is it. Take care.

Categories: Uncategorized Tags: ,