Programming

This is a classic question which I get to answer a lot. N00bs know the answer, but somebody outside the IT-business might ask something like that. This is also quite a popular question among young people trying to figure out if programming would be for them.

Anyway, here 5 Programming Languages Everyone Should Know from two people who actually have created some of the most popular languages currently used.

Nobody should call themselves a professional if they knew only one language.
- Bjarne Stroustrup

Larry Wall

See his interview: http://youtu.be/LR8fQiskYII

His list:

• JavaScript
• Java
• Haskell
• C
• Perl

Perl is not a surprise in his list. He created it in the 80s.

Bjarne Stroustrup

See his interview: http://youtu.be/NvWTnIoQZj4

His list:

• C++
• Java
• Python
• JavaScript
• C
• C#

Again, seeing C++ in his list is not a big surprise, he was one of the authors of the language in the 80s. The funny thing is that he mentions 6 languages.

Linus Torvalds

This two year old interview keeps popping up. In this video http://youtu.be/Aa55RKWZxxI mr. Linux mentions one programming language not to use.

The again, this person is well known from his more than colorful opinions about various issues. But anyway his work on Linux kernel and Git version management are well known, he is a fan of C.

me

Being a blog-author I have to express an opinion of my own. To solely copy/paste opinions of three very skilled persons is too much of a cheap thing. So, here goes:

• C
• Pretty much all languages created after 1970 owe something to C, it is imperative to know this.
• JavaScript
• When doing any kind of web-stuff, this is the only language being used in 100% of the cases. All browsers run this and it is the de-facto client-side language today.
• C#
• Very versatile compiled language by Microsoft, has lot of influence from C, C++, Java, PHP, Perl, etc. the list goes on. It is mainly used with .Net to create server-side stuff.
• PHP
• IMHO the most important web-server language there is. This is wildly popular and shares similarity with C, JavaScript, Perl, Visual Basic, etc.

In addition to learning programming languages, I encourage everybody to learn also following widely popular frameworks:

• Microsoft .Net
• Zend Framework

My reasoning between this is that if you understand how they work, you're pretty well covered and also going to Python/Django or Ruby on Rails is much easier task. I know that these are web-frameworks and people program a lot other stuff than web, but sticking to the topic of what languages to learn, these are the first ones to try. There are so many other frameworks, especially in PHP-land, but they don't have such an essential position as the framework made by people who created the PHP-language. In Microsoftland there are no other significiant frameworks to learn. Anyway, both are properly documented and lot of information can be found of them.

My favorite JavaScript-library Dojo has a very nice HTML-editor. During a project I even enhanced it a bit. Anyway the Dojo/Dijit-documentation is not the best in the world, so I'll demonstrate the three operating modes that are available. All of them have the same functionality, but how they appear visually to the person doing the HTML-editing differs.

Classic fixed size

This is the vanilla operating mode. From the beginning of time, a HTML <TEXTAREA> has been like this (without any formatting, of course). A fixed block-container of multi-line text editor which will scroll on overflow.

Example:

HTML for declarative instantiation:

<div id="terms-Editor" data-dojo-type="dijit.Editor"
    height="150px"
    data-dojo-props="extraPlugins:['insertanchor','viewsource']">
  <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
</div>

There is really nothing special, I'm just using two extra plugins insertanchor and viewsource to produce two new icons to the editor toolbar to add functionality for the end user. I found out that the plugins really need to be all lower-case for them to load properly. The class-names and filenames are in CamelCase, but putting them like that makes loading fail.

The obvious thing is that the editor is 150 pixels high. I didn't set the width, but since the editor is a simple div, any size can be set.

Auto-expanding

This is a plugin expansion for the previous. The only real difference is that this type of editor does not overflow. Ever. It keeps auto-expanding to any possible size to be able to display the entire text at once. During testing I found out that the auto-resize -code does not work on all browsers. There seems to be a discrepancy of exactly one line on for example Chrome. The bug manifests itself when you try to edit the last line, pretty much nothing is visible there. I didn't fix the bug, as I concluded that I won't be using this mode at all.

HTML for declarative instantiation:

<div id="terms-Editor" data-dojo-type="dijit.Editor"
    height="" minHeight="100px"
    data-dojo-props="extraPlugins:['alwaysshowtoolbar','insertanchor','viewsource']">
  <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
</div>

This has three things to be taken into notice:

1. The auto-expansion is achieved by plugin called alwaysshowtoolbar. It does not work in current Dojo version of 1.9.1, I had to fix it. See the patch at the end of this post.
2. It is absolutely critical to set the height="". Forget that and the alwaysshowtoolbar-plugin does not work.
3. It is advisable to set a minimum height, in my example I'm using 100 pixels. The editor will be really slim, if there is no text. This sets the size into something visually appealing.

Manually resizable

This is how a <TEXTAREA> behaves on many modern browsers. When using plugin statusbar you'll get a handle to resize the block. During testing I found out that it is a bad idea to allow the user to be able to make the editor wider. I enhanced the class with additional parameter which gets passed to plugin's constructor to limit the ResizeHandle functionality.

Example:

HTML for declarative instantiation:

<div id="terms-Editor" data-dojo-type="dijit.Editor"
    height="200px"
    data-dojo-props="extraPlugins:[{name:'statusbar',resizeAxis:'y'},'insertanchor','viewsource']">
  <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
</div>

Note that specifying the resizeAxis won't work in your code. If you really want the code I can e-mail it to you, it is longish enough for me not to post it here. The height is 200 pixels initially, but user can make the editor any size.

Hope this helps to clarify the complexity of this fine editor. It would be also nice if a filed bug report would be processed in Dojo-project. Also their discussion in Google Groups is closed, the group is set to moderate any posts, but there is nobody doing that. So, effectively new people cannot post. There is nothing left, but to complain in a blog.

Appendix 1:AlwaysShowToolbar.js patch to fix the plugin-loading

--- dojo/dijit/_editor/plugins/AlwaysShowToolbar.js.orig    2013-07-19 13:21:17.000000000 +0300
+++ dojo/dijit/_editor/plugins/AlwaysShowToolbar.js    2013-08-02 17:31:44.384216198 +0300
@@ -13,7 +13,7 @@
     // module:
     //        dijit/_editor/plugins/AlwaysShowToolbar

-    return declare("dijit._editor.plugins.AlwaysShowToolbar", _Plugin, {
+    var AlwaysShowToolbar = declare("dijit._editor.plugins.AlwaysShowToolbar", _Plugin, {
         // summary:
         //        This plugin is required for Editors in auto-expand mode.
         //        It handles the auto-expansion as the user adds/deletes text,
@@ -198,4 +198,11 @@
         }
     });

+    // Register this plugin.
+    // For back-compat accept "alwaysshowtoolbar" (all lowercase) too, remove in 2.0
+    _Plugin.registry["alwaysshowtoolbar"] = _Plugin.registry["alwaysshowtoolbar"] = function(args){
+        return new AlwaysShowToolbar();
+    };
+
+    return AlwaysShowToolbar;
 });

This is about how NOT to behave, writing about the opposite, how to behave, is way beyond me. I don't even know that myself. However, during my years in various companies and multitude of software projects, I've met lot of people. Some working quite effectively as members of a software project than others (best-of-the-best, if borrowing a quote from the movie Men in Black is allowed), and then there are the worst-of-the-worst. Today I share a story of such project member.

There is this project where I've been working as a contractor for almost 5 years now. There were some changes in the organization and I thought now would be about the time for me to do something else for a while. I discussed this with management, gave my notice and they started looking for new contractor, whom I promised to train before I leave.

Everything was fine until for my sins they gave me one (if borrowing a quote from the movie Apocalypse Now is allowed).

In the beginning it was pretty standard operations. My manager said, that there would be this new guy and he needed access to source code and ticketing. Pretty soon the new guy contacted me and asked for the credentials. I told him to hang tight so that I'd create a personal LDAP-account for him. I created the account, put in the needed groupings for a software developer -profile and handed them out to him. Nothing fancy there. Nothing that you wouldn't expect to see or do when arriving to a new assignment.

The next day he said something like "his code isn't that wonderful" to a colleague of mine. Naturally my colleague pretty soon told me what had happened. We've been working in the project together for a while and it was pretty normal reaction of him to say that the new guy is dissing your code there. I confronted the new guy and said that "Come on! We're supposed to be working together, why would you dis my work there." He surely knew how to set the initial impression.

A couple of days passed by and my colleague comes to me again: "Did you see, that he posted his LDAP-account username and password to a public bulletin board?" There is so little to do in such a situation, except OMG!! and WTF!! Why would anybody do anything like that. This is yet again one thing way beyond me. Sharing your personal credentials with other people is grounds for termination of employment!

I don't know what's going to happen next. I informed my manager that I absolutely positively won't be working with this guy. He's obviously not qualified for this job and will most likely do more harm than good for the company. However, I've been getting a lot of visitors for my LinkedIn profile lately from his connections. Looks like I've made lot of new fans for my Fan Club. Perhaps the confidentiality agreement doesn't apply to all of us? It is generally a bad idea to blabber about company's internal things with your contacts.

To recap:

• Don't criticize your colleagues' work behind their backs.
• If you absolutely need to criticize somebody's work, do it at him/her.
• Don't share passwords with anybody, they are meant to be kept secret.
• If you really know that a password can be shared, or you have permission to do so, then it's ok. When in doubt, don't do it.
  
• Don't blabber internal company or customers' issues to your friends.
• If you must do that, make sure you won't be caught doing so. When you get caught and get fired, remember I told you so.
• Take responsibility of everything you say and do. Really, that means about everything.
• This is much easier, when you say and do things people would expect somebody to say and do. If you go beyond the socially acceptable envelope, be prepared to take some heat for it.
• Then again, if you code looks like shit and works like shit, some people will call it shit. If you cannot quantify the results of your own work, then you're in shit. It is very unlikely that your work is the best there is. If you intentionally write code like shit and people call it shit, don't be surprised.