Journey to Linux Development
From weekday Microsoft .Net developer to Open Source contributor
Sunday, 20 June 2010
Update with GoogleCL
I'm currently still working on all of this (shockingly) and I'm waiting to get hold of a book for Android development. But for now I thought I'd post a quick update to try out GoogleCL (http://code.google.com/p/googlecl/), seems quite nice as a command line tool to access your google services :)
Saturday, 15 August 2009
Taking a new direction
I've been having a bit of a crisis lately (a little different to the usual ones), I've been programming in C# on the .Net framework for about 4 years professionally now and a little longer personally as I was fortunate enough to convince my employer at the time when they wanted to shift to a different technology that C# and .Net was the way to go. I still think that was the right decision as it didn't have a very steep learning curve for everyone on the development team, who already had experience in similar languages, and most of the internal users who were the intended customers already had the framework installed. And I can't really knock my own decision to learn the language as it's been paying my bills for a number of years now which is always a good thing. So what could this crisis possibly be?
As I've mentioned in a number of previous posts I've been working on C++ apps lately at work and shockingly I've been quite enjoying it, I wasn't expecting that as my previous endeavours with the language have been painful to say the least, looking back though it would seem that most of this pain can be attributed to poor learning materials but with good references such as Learn C++ and the CPlusPlus.com this has issue has been resolved. So why is this a crisis, well it's made me look at C# and .Net again and where the technology is heading and I can't say that I'm overly happy.
One of the biggest complaints I have and that I've heard from a number of fellow programmers is that the technology is moving to quickly, by the time a new feature has been introduced and you've had barely sufficient time to learn how to use it and apply it effectively a new release is out and there is something new to pick up. I've been on a few courses and to a couple of events recently and had the opportunity to speak to developers who are still working with version 1.1 of the framework because they either don't want to or simply can't keep on upgrading their apps to newer version each time they come out. I can see their point of view although I probably would try updating to a slightly newer version by now.
Another problem is with the way the language is developing, back when C# 3 came out the "var" keyword was introduced, this was a way of saying I don't know yet what this variable is going to be but figure it out for me at compile time. A number of people were wary of this wondering if this statically typed language was beginning to get lofty ambitions of trying to become a dynamically typed language, but they were calmed and told that this wasn't happening, and then with C# 4 we get the dynamic operator, hands up who didn't see that one coming!
This is really why C++ has thrown a bit of a curve ball my way, sure it does some things a funny way and it has the opposite problem of taking an age to progress technically unless you're willing to use the boost libraries, but it has a very clear identity. Python is much the same, it progresses at a good pace, letting people catch up, learn and implement new features and it has a very clear identity, it knows it's a dynamic language and doesn't pretend or attempt to be something else. All of this has prompted me to look at the languages I know, I'm going to keep C# under my belt because I've invested a lot of my time with it and Mono is starting to show some real promise (yes I am a Mono lover) plus I'm sure I'll need it to keep on paying the bills for a while yet. But I've started looking at Java as well, again it has it's quirks (type erasure and lack of unsigned types being the biggest ones) but it moves at a fairly decent pace and again knows what it is, plus it's a fairly easy migration from C# as it borrows heavily from Java. In fact I have a number of books covering things like design patterns and object oriented design which have all of their code examples in Java but I bought these as a C# developer and the converted code is almost identical.
So recently I've been running through the Sun Java tutorial book on-line and although it's hard going in some places, as the explanations of some principles aren't that well written, it's been reasonably productive. I'm not using a full blown IDE at the moment even though I have Eclipse installed because I've always thought that using a programmers text editor when learning a new language is more useful as you learn the language properly instead of relying on things like intellisense to do the work for you. And I've got Bazaar set up to version control my sample code, which has been working brilliantly I've got to say, if you're looking into version control at the moment I would strongly recommend you look at this one. For personal code its so easy to set up and use, I've got Olive installed for a GUI front-end but I tend to find myself using the command line more because it's just as easy.
I should probably also mention that another reason for choosing Java here is because I have a Google Android phone and Java is the language of choice if you want to develop apps for it, and with Ubuntu looking at bring Android apps to the desktop it means that Java apps can reach a larger audience. So I was looking at learning the language anyway but the issues I discussed earlier still just gave me that little bit more of a push.
So I'm going to keep on pushing with Java, lets see how it goes.
As I've mentioned in a number of previous posts I've been working on C++ apps lately at work and shockingly I've been quite enjoying it, I wasn't expecting that as my previous endeavours with the language have been painful to say the least, looking back though it would seem that most of this pain can be attributed to poor learning materials but with good references such as Learn C++ and the CPlusPlus.com this has issue has been resolved. So why is this a crisis, well it's made me look at C# and .Net again and where the technology is heading and I can't say that I'm overly happy.
One of the biggest complaints I have and that I've heard from a number of fellow programmers is that the technology is moving to quickly, by the time a new feature has been introduced and you've had barely sufficient time to learn how to use it and apply it effectively a new release is out and there is something new to pick up. I've been on a few courses and to a couple of events recently and had the opportunity to speak to developers who are still working with version 1.1 of the framework because they either don't want to or simply can't keep on upgrading their apps to newer version each time they come out. I can see their point of view although I probably would try updating to a slightly newer version by now.
Another problem is with the way the language is developing, back when C# 3 came out the "var" keyword was introduced, this was a way of saying I don't know yet what this variable is going to be but figure it out for me at compile time. A number of people were wary of this wondering if this statically typed language was beginning to get lofty ambitions of trying to become a dynamically typed language, but they were calmed and told that this wasn't happening, and then with C# 4 we get the dynamic operator, hands up who didn't see that one coming!
This is really why C++ has thrown a bit of a curve ball my way, sure it does some things a funny way and it has the opposite problem of taking an age to progress technically unless you're willing to use the boost libraries, but it has a very clear identity. Python is much the same, it progresses at a good pace, letting people catch up, learn and implement new features and it has a very clear identity, it knows it's a dynamic language and doesn't pretend or attempt to be something else. All of this has prompted me to look at the languages I know, I'm going to keep C# under my belt because I've invested a lot of my time with it and Mono is starting to show some real promise (yes I am a Mono lover) plus I'm sure I'll need it to keep on paying the bills for a while yet. But I've started looking at Java as well, again it has it's quirks (type erasure and lack of unsigned types being the biggest ones) but it moves at a fairly decent pace and again knows what it is, plus it's a fairly easy migration from C# as it borrows heavily from Java. In fact I have a number of books covering things like design patterns and object oriented design which have all of their code examples in Java but I bought these as a C# developer and the converted code is almost identical.
So recently I've been running through the Sun Java tutorial book on-line and although it's hard going in some places, as the explanations of some principles aren't that well written, it's been reasonably productive. I'm not using a full blown IDE at the moment even though I have Eclipse installed because I've always thought that using a programmers text editor when learning a new language is more useful as you learn the language properly instead of relying on things like intellisense to do the work for you. And I've got Bazaar set up to version control my sample code, which has been working brilliantly I've got to say, if you're looking into version control at the moment I would strongly recommend you look at this one. For personal code its so easy to set up and use, I've got Olive installed for a GUI front-end but I tend to find myself using the command line more because it's just as easy.
I should probably also mention that another reason for choosing Java here is because I have a Google Android phone and Java is the language of choice if you want to develop apps for it, and with Ubuntu looking at bring Android apps to the desktop it means that Java apps can reach a larger audience. So I was looking at learning the language anyway but the issues I discussed earlier still just gave me that little bit more of a push.
So I'm going to keep on pushing with Java, lets see how it goes.
Tuesday, 30 June 2009
Contrary to popular belief...
Well it's been over a month since my last post so I thought I'd better just put up a quick note to say that I am still here and that I haven't forgotten the blog. Unfortunately lately my better half decided that maybe we should spend some time doing the gardening so instead of investigating version control systems, playing with Mono and Python and attempting to master (or at least comprehend) C++ I've been having my arms gauged open by plants which have decided that they're not going without a fight!
I have had a brief amount of time to have a look at Bazaar and will hopefully be able to put something up about that soon, it's looking good so far and is making me wonder why we're still using cvs at work. I've also had a quick look at developing apps for the Android mobile platform seeing as I now have an Android phone, I stopped when it looked like I was going to have to invest some time with Java as I didn't want to get carried away with another language, however since then I've discovered something called ASE, the Android Scripting Environment which looks as though it allows you to write apps for Android in Python - something which is of real interest to me - so I may have to spend some time looking into that.
Anyway, keep watching for more posts shortly (honest)
I have had a brief amount of time to have a look at Bazaar and will hopefully be able to put something up about that soon, it's looking good so far and is making me wonder why we're still using cvs at work. I've also had a quick look at developing apps for the Android mobile platform seeing as I now have an Android phone, I stopped when it looked like I was going to have to invest some time with Java as I didn't want to get carried away with another language, however since then I've discovered something called ASE, the Android Scripting Environment which looks as though it allows you to write apps for Android in Python - something which is of real interest to me - so I may have to spend some time looking into that.
Anyway, keep watching for more posts shortly (honest)
Tuesday, 21 April 2009
Thank the stars for the STL
The C++ Standard Template Library is something which I've been taking for granted lately but every once in a while something happens that makes you stand back and appreciate the functionality it provides. Today was one of those days.
For reasons I'll not go into I encountered the situation today where I needed to take a hexadecimal value representing a 32 bit value and convert that into an IEEE 754 type single precision value. Fortunately after some looking around I found the entry on wikipedia which explained how a single precision value is represented in a 32bit binary value, at that point however I was having nightmares about bit shifting and XOR'ing with values to determine which bits were set!
Enter the STL, which allowed me to implement a solution which although maybe not as compact or efficient as other methods is at least easy to follow and maintain/comment. And it was all thanks to the bitset class which takes an unsigned long and represents it as an array of bits. From this point it becomes trivial to determine the sign bit, the 8 exponent bits and the 23 (plus 1 implicit) mantissa bits. So after a little reading and some coding I ended up with a method which reliably transforms hexadecimal strings (i.e. DEADBEEF) into single precision values.
Maybe not the most interesting of posts but I felt the need to share :)
For reasons I'll not go into I encountered the situation today where I needed to take a hexadecimal value representing a 32 bit value and convert that into an IEEE 754 type single precision value. Fortunately after some looking around I found the entry on wikipedia which explained how a single precision value is represented in a 32bit binary value, at that point however I was having nightmares about bit shifting and XOR'ing with values to determine which bits were set!
Enter the STL, which allowed me to implement a solution which although maybe not as compact or efficient as other methods is at least easy to follow and maintain/comment. And it was all thanks to the bitset class which takes an unsigned long and represents it as an array of bits. From this point it becomes trivial to determine the sign bit, the 8 exponent bits and the 23 (plus 1 implicit) mantissa bits. So after a little reading and some coding I ended up with a method which reliably transforms hexadecimal strings (i.e. DEADBEEF) into single precision values.
Maybe not the most interesting of posts but I felt the need to share :)
Thursday, 16 April 2009
The D Programming Language
For some reason last night I decided to have a quick look at the D programming language, it's something I've looked at briefly in the past but only in passing and never really with much enthusiasm, not because it's a lousy language but because I just didn't commit the time to having a proper look.
As I had some time off today I figured I would have a slightly more in-depth look at the D language and set up my laptop so I could compile applications. D has two compilers available, the compiler from Digital Mars and the GNU D compiler, as only the latter is in the Ubuntu repositories I opted for installing this which was a simple case of opening a terminal and typing in:
sudo apt-get install gdc
All other dependencies were taken care of and a minute later I can compile D code. Next up was an editor, I wasn't to bothered about a fully fledged IDE as I don't like to use them when I'm learning a language as I prefer to make mistakes and learn from them, but syntax highlighting would be useful as it lets me know I'm on the right lines. To my surprise my favourite Linux text editor, Geany, already comes with D support which is great because Geany also has compile/build/run options from the editor which makes it a very easy editor to work with as you can compile your code without building it and identify errors without leaving the editor. It's probably also worth noting that after a very quick investigation it also turns out the GEdit (the Gnome text editor) has syntax highlighting for D as well and Code::Blocks also has built in support.
Now for the downer, unfortunately because D is still a fairly immature language there are very few tutorials or examples out on the web so it looks like if you want to get into it then it's largely a case of studying the language specification and standard library reference. Althought from doing this it's nice to see so much functionallity in the standard library including such wonders as threading, XML processing, networking as well as standard features expected such as generating hashes (via MD5), regular expressions and string manipulation. Also available through the standard library is support for specific windows and Linux calls which makes it easier to write platform specific code.
There is also under active development a seperate library intended as a replacement for the standard library called Tango which looks promising but it is under active development so doesn't necessarily provide stability of the standard library.
So what makes D so appealing as a language? Well for a start there is the C/C++/Java style syntax which makes it easy for programmers to pick up and read. Not convinced then how about memory management? That's right D utilises a garbage collector for managing memory which means that there is less emphasis on the developer to get it right, although that doesn't mean memory is no longer a concern, for instance variables should still be declared only in the scope for which they are required.
Also of interest is design by contract, this is an interesting concept which I'm going to spend a little longer investigating but essentially it means that when you write a method you can specify a contract which can state something like "If you give me a value which meets these conditions then I will guarantee that I will return a value meeting these conditions". So when a program consumes that method it enters into a contract with the method and if either party violates that contract then the call fails, it seems a little odd at first as you can do this by running checks in code on a methods parameters and return value but with the contract you outline the requirements formally, the intention being that the contract is not broken when the program executes if it does then the program fails and fails hard.
So where does D sit in a world with .Net and Java as the two main programming architectures? Is it a niche language, a hobbyist language or something that should be taken seriously? It's certainly to early to tell how life is going go for D but I hope it goes well, at the moment I would say that it falls into the hobbyist category as it certainly doesn't seem as mature as other languages but it is getting there which is why I don't think it will always stay a hobbyist language. So should it be taken seriously? Well, yes, because D is very much C++ done right and there is still a requirement for compiled langauges instead of ones running in a VM, I am sure there will be those who will recoil in horror at the thought of having a garbage collector managing memory but I think that they work and a good garbage collector can do as good a job as a good programmer who is on the ball with memory management.
I think the future looks promising for D, as long as it doesn't slow down in development and stays relevant then in a few years we may start to see it getting some decent commercial use. I for one will be spending a little more time looking into D and getting to know it.
As I had some time off today I figured I would have a slightly more in-depth look at the D language and set up my laptop so I could compile applications. D has two compilers available, the compiler from Digital Mars and the GNU D compiler, as only the latter is in the Ubuntu repositories I opted for installing this which was a simple case of opening a terminal and typing in:
sudo apt-get install gdc
All other dependencies were taken care of and a minute later I can compile D code. Next up was an editor, I wasn't to bothered about a fully fledged IDE as I don't like to use them when I'm learning a language as I prefer to make mistakes and learn from them, but syntax highlighting would be useful as it lets me know I'm on the right lines. To my surprise my favourite Linux text editor, Geany, already comes with D support which is great because Geany also has compile/build/run options from the editor which makes it a very easy editor to work with as you can compile your code without building it and identify errors without leaving the editor. It's probably also worth noting that after a very quick investigation it also turns out the GEdit (the Gnome text editor) has syntax highlighting for D as well and Code::Blocks also has built in support.
Now for the downer, unfortunately because D is still a fairly immature language there are very few tutorials or examples out on the web so it looks like if you want to get into it then it's largely a case of studying the language specification and standard library reference. Althought from doing this it's nice to see so much functionallity in the standard library including such wonders as threading, XML processing, networking as well as standard features expected such as generating hashes (via MD5), regular expressions and string manipulation. Also available through the standard library is support for specific windows and Linux calls which makes it easier to write platform specific code.
There is also under active development a seperate library intended as a replacement for the standard library called Tango which looks promising but it is under active development so doesn't necessarily provide stability of the standard library.
So what makes D so appealing as a language? Well for a start there is the C/C++/Java style syntax which makes it easy for programmers to pick up and read. Not convinced then how about memory management? That's right D utilises a garbage collector for managing memory which means that there is less emphasis on the developer to get it right, although that doesn't mean memory is no longer a concern, for instance variables should still be declared only in the scope for which they are required.
Also of interest is design by contract, this is an interesting concept which I'm going to spend a little longer investigating but essentially it means that when you write a method you can specify a contract which can state something like "If you give me a value which meets these conditions then I will guarantee that I will return a value meeting these conditions". So when a program consumes that method it enters into a contract with the method and if either party violates that contract then the call fails, it seems a little odd at first as you can do this by running checks in code on a methods parameters and return value but with the contract you outline the requirements formally, the intention being that the contract is not broken when the program executes if it does then the program fails and fails hard.
So where does D sit in a world with .Net and Java as the two main programming architectures? Is it a niche language, a hobbyist language or something that should be taken seriously? It's certainly to early to tell how life is going go for D but I hope it goes well, at the moment I would say that it falls into the hobbyist category as it certainly doesn't seem as mature as other languages but it is getting there which is why I don't think it will always stay a hobbyist language. So should it be taken seriously? Well, yes, because D is very much C++ done right and there is still a requirement for compiled langauges instead of ones running in a VM, I am sure there will be those who will recoil in horror at the thought of having a garbage collector managing memory but I think that they work and a good garbage collector can do as good a job as a good programmer who is on the ball with memory management.
I think the future looks promising for D, as long as it doesn't slow down in development and stays relevant then in a few years we may start to see it getting some decent commercial use. I for one will be spending a little more time looking into D and getting to know it.
Friday, 10 April 2009
Assignment FAIL!
One of the things I've been having to do lately is make sure that my C++ complies with high integrity C++ rules and guidelines (HICPP) which though interesting has been a massive pain as I've gotten use to doing things in a certain way and now I have to double-check everything I write for compliance. One which takes more getting use to than most is the use of the comparison operator in control statements, normally I (along with most people I think) would do a check something along the lines of "if my value is equal to three then...", or
Now this is invalid in HICPP because a programmer could accidentally type "if (x = 3)" which of course is assignment instead of comparison, so the rule states that instead the comparison should be written as
The reason for this is that the former is perfectly valid C++ syntax and will compile and run (but not work), whereas the latter will cause a compiler error because you cannot assign a value to a literal value.
This is one of a few rules which I am likely to carry into my every day coding as it helps to prevent me from making stupid mistakes which as a human I am more than capable of making. Another one which takes only a little more effort but can save until problems is when looping over a collection, the rules state that instead of doing this...
It should be written as...
Which again makes sense as with the latter method you avoid problems if the length of your collection changes. Of course this doesn't work so well if the loop is suppose to change the size of the collection, but that's a reasonable exception.
int x = 3;
if (x == 3) { ... }
Now this is invalid in HICPP because a programmer could accidentally type "if (x = 3)" which of course is assignment instead of comparison, so the rule states that instead the comparison should be written as
int x = 3;
if (3 == x) { ... }
The reason for this is that the former is perfectly valid C++ syntax and will compile and run (but not work), whereas the latter will cause a compiler error because you cannot assign a value to a literal value.
This is one of a few rules which I am likely to carry into my every day coding as it helps to prevent me from making stupid mistakes which as a human I am more than capable of making. Another one which takes only a little more effort but can save until problems is when looping over a collection, the rules state that instead of doing this...
vectorvalues;
// Add values to collection
for (int i = 0; i < values.size(); i++) { ... }
It should be written as...
vectorvalues;
// Add values to collection
int size = values.size()
for (int i = 0; i < size; i++) { ... }
Which again makes sense as with the latter method you avoid problems if the length of your collection changes. Of course this doesn't work so well if the loop is suppose to change the size of the collection, but that's a reasonable exception.
Sunday, 22 March 2009
What a Git!
Unfortunately I've not been able to do much with my mono algorithm project lately since publishing the first piece of code which is a shame, the plan though is to start implementing different algorithms starting with some from the C++ STL library. I don't really have a plan yet of which ones so it will most likely be which ever ones interest me and which I'd like to learn more about such as binary searching and various sorting algorithms.
One thing this has prompted though is version control, and I now realise that I really don't know enough about them. Historically I've been use to commercial systems with nice UI's letting me point-and-click for what I want to do. Now however I've got to think about working (possibly) with more people spread over a larger area and not the few guys sat around me. Because I went with Google Code in the end I've restricted myself to Subversion which isn't to bad as I have at least a little experience with CVS but I still could really do with learning the basics again.
I am a little disappointed however as I've recently been reading about using distributed version control systems such as Git and Bazaar which I really love the idea of using. One of the things I really like is having local branches to work on which have no impact on other peoples work unless they start viewing my repositories. The advantage of this has become clear lately at work where a few of us are working on a project where each section is being developed in a seperate branch in CVS, the problem here is the proliferation of branches and keeping track of them. In a distributed world we would all work independently of each others branches and then commit our changes to a main repository which would hold the final code base.
Anyway, I'll need to pick up Subversion soon but I think I'll be investigating the distributed systems as well as I think that they are the way forward.
One thing this has prompted though is version control, and I now realise that I really don't know enough about them. Historically I've been use to commercial systems with nice UI's letting me point-and-click for what I want to do. Now however I've got to think about working (possibly) with more people spread over a larger area and not the few guys sat around me. Because I went with Google Code in the end I've restricted myself to Subversion which isn't to bad as I have at least a little experience with CVS but I still could really do with learning the basics again.
I am a little disappointed however as I've recently been reading about using distributed version control systems such as Git and Bazaar which I really love the idea of using. One of the things I really like is having local branches to work on which have no impact on other peoples work unless they start viewing my repositories. The advantage of this has become clear lately at work where a few of us are working on a project where each section is being developed in a seperate branch in CVS, the problem here is the proliferation of branches and keeping track of them. In a distributed world we would all work independently of each others branches and then commit our changes to a main repository which would hold the final code base.
Anyway, I'll need to pick up Subversion soon but I think I'll be investigating the distributed systems as well as I think that they are the way forward.
Subscribe to:
Posts (Atom)