For those who have been keeping up with the latest news in the web development world, you’ve probably seen the introduction of TypeScript. I have heard the perspectives of many other people on this new language, but I wanted to actually work with language a bit before I started deriving my opinion. Given that I have worked with it for a few of weeks now, I think it’s about time I put something in writing.

Before I talk about TypeScript, let’s get one thing out of the way, attempting to develop large-scale applications with maintainable and testable code in JavaScript is horrific. Note, I did not say that it was impossible. If you disagree, then I would highly suggest you read a couple software engineering books such as The Art of Readable code by Boswell and Foucher, or The Pragmatic Programmer by Andrew Hunt. If you still disagree after reading those books, work a while on larger scale projects using C++, Java, C#, Python, or some other more traditional language. If you still “don’t see the light,” I’m sorry, there is probably no hope for you and you might as well stop reading now.

What is TypeScript?

TypeScript is an open-source superset of JavaScript. In essence, its creators acknowledge that people aren’t going to get rid of JavaScript anytime soon, but people still need to create large-scale maintainable applications in JavaScript. As a result, the authors of TypeScript decided to expand JavaScript to make it faster to develop, easier to maintain, quicker to debug, faster to tool, and make the development experience better for large-scale app development. TypeScript uses a compiler to handle modules, classes, type inference, and module dependencies; all of which help accomplish some of the goals mentioned.

Who is the publicly visible team that has developed TypeScript?

Generally speaking, a language can live or die based on the architects of the language. As a result, it is important to know who is behind it and how likely are they to continue their efforts. From what we are told, the primary visible team contains Steve Lucco, Anders Hejlsberg, Erich Gamma, and Luke Hoban. If you are a professional software engineer, at least two of those names should mean something to you and should give you some confidence in the design, direction, and possible lifespan of the language.

Pros & Cons

Pros

• Open Source
• Compile-time syntax and type (if types are specified) checking.
• Allows for OO paradigms to be utilized in development. This is very important for full-scale application development.
• Type inference. Takes advantage of the dynamic typing that JS provides, but allows for some structure around it if desired. Allows for intellisense like completion when used.
• Generates JS output in ES3 and ES5 for better back compatibility.
• Allows the usage of pure JS libraries through definition files. That means that you don’t have to port every library you want to use.
• Takes the pain out of AMD (such as Require.JS) or CommonJS module loading.
• Simplifies continuous integration substantially. I was able to put together a full Jenkins CI TypeScript project using Node, Gradle, Jasmine, and Require.JS in a very short time. I’ll talk about that some other time, but for now I have pushed up a copy of that project to my GitHub for you to check out.

Cons

• As with any language that compiles to another, there is always a disconnect between the code that is written and the code that is generated. To remedy this, it appears that TypeScript attempts to leave as much of the pure JS that is written within functions alone. From my experience, it pretty much copies it verbatim.
• External and Internal module loading isn’t documented really well and can be a bit of a pain to figure out for complex module structures.
• Only a few definition files are available right now as the language is so new. However, this is changing through the DefinitelyTyped community project.
• Tutorials and documentation are a bit scarce due to the age of the language.
• Autocompletion is only available in VS2012 and syntax highlighting is only available in a select few editors. While I expect for this to change, it is the reality when this post was written.
• The language is still in “preview”

Opinion

I personally believe that TypeScript even in its current “preview” form allows for faster, easier, and better development for the current web development situation. While I have only written about 1000 or so lines of it at this point, I can definitely state for the record that it’s a breath of fresh air to the aged and stagnate conglomeration that is JavaScript. Coming from someone who has worked with many languages, one of the most important things I look for in a good language is being able to utilize language agnostic skills, concepts, and techniques within a given language. I know many web developer’s diss the need for traditional OOP concepts that TypeScript brings. However, I would argue that it is a very important requirement for full-stack or traditional developers.

Outside of all of the other things that TypeScript brings, probably one of the most important pieces is the compile-time checking. Sure JavaScript has JSHint and JSLint, but anyone who has used those knows that they only catches the basics. TypeScript on the other hand will tell you the full story. A simple example is if you try to assign a string to a variable that is currently a number. TypeScript would throw an error due to mixed assignment. While this may seem trivial, such a simple check can save you valuable debug time. The idea is to allow the compiler to do the hard work for you during development time.

As a side note, It is also my personal opinion that anyone who complains about TypeScript bringing structure, type inference, more traditional OO paradigms, and Lambda functions to JavaScript should take a hard look at what they know. In my mind, any professional software engineer should understand the importance of structure and why traditional OO paradigms are absolutely necessary for developing large-scale maintainable applications. It’s not that to say that you can’t develop large scale apps without it, but rather it is horrible to do so and for your own sanity you shouldn’t.

Recommendation

I highly recommend TypeScript. Even though it is currently out as a preview, I believe that the core concepts are solid and probably won’t change too much. It scratches an itch that has gone unscratched for many years until now. It acts as a bridge technology so that older browsers aren’t left behind while still being compatible with the plethora of JavaScript libraries in existence. I hope you will spend some time with it and see what I’m talking about first hand. Hop on over to the TypeScript website and give it a shot.

Tags: Languages, Open Source, Review, Software Engineering, TypeScript

Thanks to everyone who has been using Cuckoo over the past few months! I haven’t had much time to implement some of the features that y’all have requested, but I will try to look into them as soon as I have some spare time. In the meantime, I have covered few couple of major requests.

Updates:

• Added support for Quantal (Ubuntu 12.10).
• Added basic internationalization support.
  • While there are still some issues that need to be resolved, the project now allows for community translations to be submitted through Launchpad. If you would like Cuckoo in your native language, you should be able to contribute on the Launchpad translation page. The daily PPA should automatically build your changes within about 24 hours.
• Added minimize on start feature.
  • A number of people have requested this feature for a better user experience.

Other news:

Get Cuckoo

Software Center	Stable PPA:	Daily PPA:
	ppa:john.vrbanac/cuckoo	ppa:john.vrbanac/cuckoo-daily

Tags: Apps, Cuckoo, Linux, Python, Quantal, Releases, Ubuntu

Background

Why

Results

Tags: Linux, Ubuntu, Unity

A few weeks ago, Mark Shuttleworth announced the Unity WebApps concept. Personally, I love the concept; however, I noticed that there was support for gmail, but I couldn’t find support for the RoundCube webmail client I use on my own servers. To remedy this, I decided to write a plugin for roundcube that adds Unity WebApp support to your self-hosted RoundCube instance.

Features:

•     Allows you to go straight to composing a new message or viewing your address book through the launcher or the HUD.
•     Adds HUD Entries for each one of your mailbox folders.
•     Adds MessagingEntries for every folder with unread messages.
•     Shows a Unity notification when you recieve a new message.
•     Shows the number of total unread messages, across all folders, on the Unity Launcher icon.

You can find the latest version on the Launchpad project:
Project Page:  Launchpad Project
Plugin:  Download

Note: Currently the plugin is only supported with RoundCube 0.7.2+, so it may or may not work for older versions.

Known Issues:

• I have also noticed that occasionally, Firefox 14.0.1 (only seen on the latest version) will just crash the first time accessing the page; restarting Firefox seems to resolve the issue. I haven't discovered what is causing this and it doesn't appear to extend to Chromium.

Tags: Download, Launchpad, Plugins, RoundCube, Ubuntu, Unity, Web API, WebApp

I've pushed out a new version of Cuckoo. I fixed a number of UI issues that were bugging me; including the list sorting issue that I mentioned earlier. I believe that I also fixed the locale issue that clepto1995 (reddit user) reported. Thank you for finding that! Please let me know if y'all see any bugs that need to get tackled. If you have ideas for features or would like to get involved with the project just let me know. Thanks!

Screenshots:

• Main Window
• Edit Window
• Preferences Window
• Application Menu
• Indicator
• Unity Launcher

Launchpad Project: https://launchpad.net/cuckoo-alarm
PPA: ppa:john.vrbanac/cuckoo

Installation:

 
sudo apt-add-repository ppa:john.vrbanac/cuckoo
sudo apt-get update
sudo apt-get install cuckoo

Tags: Alarm, App Showdown, Cuckoo, Linux, Python, Ubuntu

Cuckoo is ready to be beta tested! I had an issue with packaging on the build servers that I had to fix before I could get this thing out. With that fix done, you can find Cuckoo in the PPA mentioned below.

There are still a few UI issues that I’m working on, but you should be able to give this thing a go. One of the UI issues that’ll be addressing is the list sorting. Currently, the alarm list doesn’t sort at all. I hope to have that done late tonight after I get off work. Please report any bugs you find on the Launchpad project page. Thanks!

• Launchpad Project: https://launchpad.net/cuckoo-alarm
• PPA: ppa:john.vrbanac/cuckoo

Installation:

• sudo apt-add-repository ppa:john.vrbanac/cuckoo
• sudo apt-get update
• sudo apt-get install cuckoo

Tags: Alarm, App Showdown, Cuckoo, Launchpad, Linux, PPA, Python, Ubuntu

I normally don’t get involved in contests, but I recently heard that Ubuntu is having a 3 week application contest. If you know me, I’ve been using Linux for the past 12 years and became an avid supporter of Ubuntu when it surfaced many years ago. To help show my support, I figured I could toss together a quick application over the remaining time to scratch an itch that I’ve been hoping someone would take care of for a long time. 

Meet: Cuckoo

Cuckoo is a simple no-frills alarm clock application that is user friendly and designed with Ubuntu in mind.

Concept Window Screenshot:

While there are a couple of alarm apps that I have used over the years, they aren't the easist to manage, and have gained a bit of feature bloat over the years. Ideally Cuckoo will eventually be the simple and intuitive alarm app that I have wanted for so long. Considering my schedule and that there is only 1 ½ weeks left in the showdown I doubt that the first release will be anything more than basic functionality.

Once I get some of the framework down, I’ll push this thing up to a PPA for y’all to try.

Tags: Alarm, Apps, Cuckoo, Development, Linux, Python, Software, Ubuntu

Over the past few weeks i’ve been writing a few interactive console-based python utilities. To cut down on my development time, I wrote a quick and dirty interactive console application base for python. I wrote it in like 10-15 mins, so it’s probably not that robust; however, you might find it useful for small utilities that you may be writing.

 

# Create an instance of ConsoleInterface 
console = ConsoleInterface()
 
# Add your commands 
# First argument: The command text string to trigger a function 
# Second argument: Pass in the function that you want called on command. 
console.add_command("sample", sample_function) 

# Turn on the console 
console.activate() 

Tags: Application Base, Code, Console, Python, Utilities

The shotgun approach is best described as shooting first at a target without knowing where or what the target really is. For the sake of this conversation, let’s say the target is a defect in an application. Often it seems like the shotgun approach is practiced by reckless and or inexperienced developers who really don't have a clue about where to start solving a problem. It is also common among developers who do not have a solid coding standards or lack a proper software development methodology to guide their workflow.

Let's get something perfectly clear. While the shotgun approach can eventually hit the target, it is rare and usually is very costly in regards to productivity. To compound the problem, the loss in productivity in a team of developers with a shotgun approach goes up at an exponential rate for every one of the developers involved. Think of it this way, the shot pattern gets wider for every developer that utilized this approach. In addition, the wider pattern doesn’t mean that you are more likely to hit your target; quite the contrary. The number of potentially invalid ideas that these developers will end up exploring will be quite substantial.

So what can you do to avoid the shotgun approach? First and foremost, always approach the solution from the simplest angle possible. Second, keep to the core principles of software development. This means different things to different people, so in the future I’ll will address what I believe to be the guiding core principles for every professional developer. Third, remain calm. When all heck is breaking lose, it is very easy to get caught up in the firestorm of the situation and not approach the problem with a clear head. Finally, do not let management distract you from the first three.

If you are in management or a project lead:
I understand that the pressure on us can get intense, but please do your best to not distract your developers with rabbit trails. The developers we lead generally feel an obligation to at least consider our ideas. We can try to steer them in the right direction. However, placing more pressure on our developers and having them explore rabbit holes will only exacerbate the problem we are trying to deal with.

Tags: Problem Solving, Reckless Developers, Shotgun

There is no such thing as perfection in the world of software. In fact, a developer who believes they can actually achieve perfection or can produce perfect code is unbelievably dangerous. Why? When a developer believes that it is possible to produce perfect code, they refuse to see what could actually go wrong. This is equivalent to a blind person attempting to cross a busy freeway unassisted. Sure they might make it, but it is definitely not safe, and absolutely not recommended.

Let me be clear, this is not a free pass to skimp on quality. Just because we can’t build the perfect system, doesn’t mean that we shouldn't strive for one. See, while we understand that we cannot create perfect code, we as developers should still always pursue it. However, we should pursue perfection with eyes open to our own faults and potential shortcomings. We need to focus on developing the best code we can while making sure we are looking for all the junk that could potentially go wrong with it. Murphy’s law is always at play with software when it is deployed. However, when we take time to discover what could go wrong during development, we can take appropriate action to create assertions, unit tests, error handling, and/or exception handling to help mitigate the potential fallout. When the appropriate actions are taken, we can deliver a much higher quality product. So in essence, you can’t develop perfect code, but with the proper checks and balances in place you should be able to get relatively close.

Tags: Perfection, Software Engineering