As well as that I was hoping to find something I could use something to enforce a style guides on my code, because I know most editors do a poor job of this task.
You first friend in writing great code is the compiler. Clang (the underlaying compiler for the Mach and iOS platform) tells you when you’ve done things wrong. In the JavaScript world we have to worry about whether we’ve provided the right number of arguments to a method, whether we have the order correct and whether we have provided the right object types.
This is easy to validate in most situations but when you get to a reasonably large code base, it gets harder. When you are changing code/interfaces of classes it gets harder.
As well as being able to check the syntax and general correctness of your code, the Clang compiler does some static/semantic analysis of your code.
There is even Xcode support.
Once you get passed the CLang analysers you still be hungry for more tools to keep your code clean. There are open source projects to produce lints/static analysers for Objective-C.
As far as linting is concerned I’ve found a couple of projects.
OCLint says it is:
"A static code analysis tool for improving quality and reducing defects by inspecting C, C++ and Objective-C code"
The project has been around since the 1st of January 2013, as of writing it had hit 0.10.2. It hasn’t had the most consistent of release schedules but does seem to getting a lot of interest from the wider Github community.
It’s written in C++ primarily, so it’s got the potential to be cross platform if you were in the market to run static analysis on non-Mac hardware. Though I haven’t confirmed that yet.
Infer is tool built by Facebook which is:
"A tool to detect bugs in Android and iOS apps before they ship".
It’s relatively new (first release being the 11th of June 2015). It’s written in OCaml, runs on a Linux box, but there are no guarantees about it’s perform on code bases outside Facebook.
The only real player in town for beautifying/enforcing style seems to be Uncrustify. The main aim of the project according to it’s creators is to:
"Create a highly configurable, easily modifiable source code beautifier"
I’ve heard great things about Uncrustify, the C++ community really seem to appreciate it, so I’m looking forward to being able to finally use it myself.
Swift is the future of iOS and Mac. I’ve been experimenting a little bit with the language over the last while as well, Objective-C is still my main focus, but I get tempted by all the great things I hear on podcasts…etc
As far as linters are concerned the two main players are:
Unlike the Objective-C linters I found, SwiftLint is written itself in Swift. This project was started on the 18th May 2015. It’s based on the Github Swift Style Guide, so you know it’s opinions are based on some solid hard won experience.
Tinker, tailor, solider, spy… this linter is written in Java. Which means it’s definitely cross platform. Which gives you the options such as; say you had a centralized source control system and wanted to run a linter on a pre-commit hook. The project had its first release on the 19th September 2015, so a little later to the game than SwiftLint, but both are basically spring chickens. I don’t know how well Tailor would work if you wanted to integer with a development environment though.
This is by no means an exhaustive list. There are many tools coming out everyday to help with code quality (more for Swift than Objective-C obviously). As time goes by, and as I discover better tools, I’ll likely write about this topic again.
Below are links to web pages/articles I used to create this article.
So it’s probably of no surprise to discover that all my current iOS development efforts have been focused on Objective-C.
I know that in the long term, I’m almost certainly on the wrong side of history. I don’t think this would be the right choice for everyone. I’m just saying that I believe it is the right choice for me right now.
For me a lot of things stand about about Objective-C over Swift. As of today there is more production code in the wild written in Objective-C than there is Swift. It’s had a 30 year head start after all. Sure the tide is changing pretty quickly, but the expansive array of libraries/frameworks and tooling that exists is immense and not something to turn your nose up at. As well as anything else; the community is large and I believe there are a lot of really great people I could learn from.
If at any stage in the future I wanted to persue iOS development in a serious way, like working with a team. There is a high likelihood/possibility that a real companies iOS code base will be 99% Objective-C based. It takes a long time for teams working on business critical applications to do something dramatic like switching programming languagues. There are inheret risks to a decision like that.
A bit of research will find that there are nices way of bridging code across the Objective-C/Swift gap and I’ll definitely be exploring that in my own projects on this blog.
A big factor for me and learning Objective-C over Swift is I feel, rightly or wrongly, that Swift will likely be easier for me to learn. It has more modern features/syntax that is familar and similar to languages I’ve used in the past. Where as Objective-C is a bit of a departure. The unusual veener hide a familiar OOP language, but I feel the learning curve for me is higher. I know that it’ll serve me in the long run to learn it now and work with it now while I wait for Swift to mature just that bit more, and for the community/tooling to come along just that bit more.
"But really the most imporant things you can do is to learn how the Apple APIs work. Once you do that, the language you write in is just syntax and highlighting."
This is a pretty short post. It’s a clear enough decision for me right now. But if you’d like to hear what someone who has more experience has to say about it, watching the above video by iOS engineering Eric Miller.
It’s a doctor and they tell you it’s not good. I’m afraid it’s your worst fear. ‘We’ve done some ECGs, and they have confirmed our worst fear. It’s a ST elevated MI. I’m afraid we’ve caught it a bit late, our best people are currently in the middle of PCI. Oh, look at the time. I really must be getting back. Goodbye.’
Jargon can be useful. It’s a way of packing a complex idea into a tight space giving you the scope to connect high level ideas together. The only trouble with jargon is that everybody involved needs to be “on the same page” as it were (aware of the meaning of the phrase, the concept that is being conveyed and perhaps even be aware of what it does not mean).
In the case of the introductory passage above, MI stands for “Myocardial infarction” or more simply heart attack.
What I’m finding in my efforts around learning the iOS platform is that there is a vast body of jargon, concepts and ideas that I don’t know. Or at least if I do know I don’t know in a formal way to help me help someone else to get the idea.
That is why I’ve decided that while I’m learning the iOS platform I intend on keeping a log of the jargon that I encounter. I’m going to try and keep this Jargon Busting sheet up to date and explain items in a ways that I understand these ideas and concepts. Hopefully my little project might be of some use to someone in the future.
Whether it’s my text editor of choice (Sublime Text) or a development environment (Eclipse, Visual Studio). That is why in my journey to understand the iOS platform an important step is to learn about the tool that will assist me the most in that goal, Xcode.
I’m coming from the web and I see a lot of people saying that IDE are pointless/not the way to do things. I’ve said it myself. In previous positions I would always rather a clean text editor with clean editing concepts over a bloat mess of an IDE any day. I even debated the point of view that having an IDE made doing the wrong thing too easy (Eclipse Java auto-complete anyone?). I do sometimes feel that way, but I’ve seen badly written Java done using text editors as well as badly written Java using IDEs.
I’ve had more experienced programmers explain to me what they believe the true power behind an IDE really is. An IDE exists as a way of treating code not as symbols in a UTF8 text file, but as living breathing data that you can manipulate and interact with. An IDE is an extension of the the compiler/interpreter that understands your language. The compiler/interpreter spits out ASTs (abstract syntax trees) of the various parts of your program and the IDE can consume and use that to inform you of deep power things.
Xcode understands the relationship your code has to the rest of the underlaying framework. It can show you the right information at the right time to help you make the best and most informed decision.
Arriving in to Xcode is overwhelming at first, as it can be with any reasonably complex development environment, but after a little while I started to get a sense of what was what, and where was where. There are a few main sections from what I can see:
On the left hand side of the Xcode interface are the navigator tree interfaces. These are a collection of tabbed views that give me a high level insight into my application. The first and most important one is the Project Tree Navigator.
It does what you’d expect. It reads the structure of my code on disk and displays a tree to represent it. It provides me with a right click context menu as for file and folder operations.
I noticed on the bottom of the navigator view you get a filter component which filters the tree to show you just the files you want. Which is a very useful features.
There are a few more navigators available in that view, but I probably won’t find them useful at first, but here is a list and a brief explanation:
Just a side note on Xcode and projects. Even though it appears that I’m moving things around into folders in Xcode it doesn’t actually do that on disk. It only does that grouping into a folder in the Xcode project. My actually files will remain scattered around that main folder like I never organized anything.
I did happen upon a SO question which clears up how to approach this issue as I’m sure that I’m going to want to interact with the code outside Xcode (through Git command line…etc.) as well as inside it. It does seems a bit mad that it wouldn’t do a grouping on the files system as a way of representing these groupings, but I’m sure there was an original rational behind it that made sense to the development team.
Of all the pieces of Xcode I’ll need to understand the most, the editor area is the most important. It is where the ideas stream out of my head and into reality. The interface is split between it too main aims. Writing code and creating UIs.
As a text editor Xcode is pretty okay. I’m still getting used to it. I was quite frustrated at first, because I had gotten so used to the incredibly advanced features of tools like Sublime Text that I find it quite slow to create anything in it, but I’m sure I’ll get the hang of it soon and I’ll share those insights on this blog at a later date.
I liked the fact that the key bindings are all completely configurable which is handy. And it seems that you can import an XML document with those binding into and out of the editor. I’ll probably start to tweak these to something more suitable to my particular muscle memory over time. The other large element of this part of the editor seems to be the breadcrumb.
The breadcrumb is useful in a number of ways. Firstly it lets me get an outline of the specific file I am working with. It exposes object hierarchies if I am using a file which has inherited from another object, or perhaps implements an interface/protocol of some kind. It also shows logically connected files, like an interface and an implementation files if you are talking about Objective-C or an Storyboard view and a Swift file.
There is of course the usual features you’d expect here also like code folding, line numbering, comment toggle…etc
Interface Builder is an alternative editor view that does much more than designing interfaces through dragging and dropping components. Here are some of it’s responsibilities.
There is clearly a lot going on here, and I’ll probably be digging deeper into this at a later date.
Like every application and every home there is a place where the little bits and pieces must live the utility area is that place for Xcode.
This is where various property dialogs are displayed for the file which is in focus (typically); items such as UI settings, styling, sizing…etc. All of the various contextual property elements find there way into this area.
The library pane is where I can do lot of different little things. There are various sub sections such as:
The next section of the editor that I said I’d look at is the toolbar. What I find interesting about the toolbar is that it take a few designs/nods from iTunes. You have large controls to the left and right the control an overall operation, while in the center you have a currently active operation/progress bar. It’s a nice touch and make it easy enough to understand the intents of the toolbar at a glance (if you’ve previously used iTunes).
It’s primary role would be context switching. Switching to the context of running your application, stopping it. Changing the current editor type.
The main run controls allow me to kick off my app in the simulator/emulator mode. It even allows me to choose different target devices to run against (iPhone, iPad…etc). Being able to switch these quick seems quick hand if I were to be targeting multiple devices.
The view buttons allow me to move between different editing contexts.
The final elements in the toolbar are the pane toggle buttons. These are a quick and convenient way hidden unnecessary parts of the UI. In the version of Xcode I’m using (7.1) the buttons have a visual impression of the pane section that they hide.
Finally there is the debug output area. I’ve done some debugging and seen the stack trace there, I’ve played with inspecting variables/objects and done some print debug. It’s pretty much what I’d expect.
Finally there are the advanced features that it’ll be a while before I really get my teeth into.
There is a whole build system technology build directly into Xcode. I must properly investigate this before writing about it. I don’t like build technology that I can’t automate. If I can’t produce a set of build steps that I can then run on some sort of continuous integration server (at the very least on a nightly task, perhaps on a different user account) then I think I’ll look at some other method to build my applications.
Xcode is a vast, vast tool just like any IDE. As I get more experience in it I’ll be able to write posts that go into depth about different elements of it’s functionality.
The following are the various links I reference to write the article above. Any links I used throughout the article can be found here.
To help me get to grips with learning a new platform I like to compare and contrast it to one I already know. That way I end up having a kind of base to build off of, and it helps me internalize some of the details a bit quicker. So the question I asked myself was, how does iOS compare to the stack I’ve been using these past several years. The browser.
So before I started I wrote down everything I know about the browser and it’s architecture as a starting point for myself.
I have to admit when I start sketching out what I know I notice a few general gaps in my own knowledge. Many specific details about how events/interactions occur were actually a little bit of a mystery to me. I happened upon a blog post By Tali Garsiel and Paul Irish on HTML5Rocks which breaks down the browser and it’s internal structures really well. A lot of the detail is too fine grained and unnecessary dense for my purposes here, but it’s actually quite valuable to know. For instance if you never understood how the layout/computed style system work (dirty bits) and how changes to the DOM can ripple out pretty dramatically then you might of questioned the point of that whole React Virtual DOM business. You might also question your own web app keeping it’s application state so tightly integrated (even stored) to the DOM in the form of data attributes/classes…etc
To save you a trip over to Tali and Paul’s article here is a quick break down:
So that is basically your client platform infrastructure. Obviously, a web application typically has a server side component, which could include Apache, MySQL, PHPs, Java and even now, JavaScript. I won’t go into that right now for the sake of clarity.
The type of work I do as a web developer is to:
So as such the question I’d have for the iOS platform is:
So now that I have general sense of the architecture I typically use and questions to help me direct my exploration; I wanted to see what would be the equivalent elements in iOS that map to these browser elements.
There are a few layer here, and none really directly translate perfectly to the browser architecture, but you get the idea. As you go down through each layer, you are getting to lower and lower levels of abstraction until you hit the Kernel (which you have almost no way to interact with). There is a lot to unpack here so lets get started.
Cocoa Touch is high level set of APIs which developers seem to spend most of their time in. This is where a lot of the high level APIs that help developers get things done are located. There are a few key/famous APIs at this level that are really important, UIKit being an example of one. There are also mechanism exposed at this level to help developer do things like multi-tasking, laying out their application, designing the application to be responsive on multiple screen sizes, handling complex user interacts through gesture recognition, capturing application state and interacting with other applications.
In a sense the Cocoa Touch layer represent a lot of different elements within the browser rendering engine and within web application frameworks that you might use. It does not translate directly to any element within the basic browser architecture, which isn’t surprising.
The Media Layer is were a lot of the more complex graphics/rendering/audio technologies relate APIs reside. If you’ve even had a passing interest in Apple announcements you might of heard of one API within this layer which is called “Metal”. Metal is supposed to be a fairly low level graphics API suitable for use by games engine developers and people who make graphically intensive applications.
The only experience I’ve had with doing low level drawing on the web was with Canvas and help from a few different JavaScript libraries. The kind of things I did there would probably happen at this level.
Other pieces in the media layer include ones centered on audio & video, to allow you to interact with the camera/video recorder and microphones of an iOS device. As far as the browser is concerned a lot of the APIs that expose the same type of functionality come from the “UI Backend” layer. You might have a high level binding in JavaScript to allow you to access the web cam (WebRTC for instance).
Core Services is as low as most applications get. This is where you find one of the most fundamental iOS APIs, the “Foundation” API. This is a related piece of the architecture called Core Foundation which is a C based API and collection of data types which developer rarely need to go near. Foundation on the other hand is an Objective-C (and Swift) based API.
Other services at this layer are:
The Core OS is the deep dark bowels of iOS. Specifically though, this is where you would go to get fine grain control over data from the Bluetooth radio, various security related services, the Network Extension framework (for working with VPNs) and a variety of little System APIs. There is also a very interesting set of APIs for “discrete signal processing” (DSP) and other complex mathematical operations. If you wanted to get really heavy into Instragram filters this would be the place to go :P.
So after a good bit of digging into the Apple Developer docs I still felt a bit mystified as to the questions I set out with, so here is a breakdown of what I’ve discovered.
The native languages that I’m going to be using when developing anything in iOS seem to be:
There is also a JavaScript VM available to use a part of the overall iOS architecture. But I’m to understand that it can be quite complex to use and to interact with the rest of the system… and anyway, you’re here to learn something new, not get things done :P.
Rendering is largely taken care of by the OS through a set of drawing systems called Core Graphics (formally known as Quartz). There are many layers that built on top of Core Graphics which abstract away the complex details found there. Ultimately, if all I want is a button I may never need to go too deep into the rendering engine/APIs. In the browser application world we are more concerned with rendering because it can have a real impact on application performance. Yes this is a concern to iOS developers but not in the same way as it is in the browser.
The primary network API is called NSURLSession, this is exposed in the Foundation framework (Core Services). If you intend on contacting third party web services or say your own server backend this is where you might want to go. However, if you were making an application primarily keeps it’s state locally on a device and you were concerned with backing that data up somewhere then you could look to using Core Data and iCloud infrastructure which are found in the Core Services instead of building out a whole crazy backend for yourself.
Events and user interaction are baked into the UIKit and other frameworks at the Cocoa Touch level. As I mentioned previously there is a gesture recognition system found there, so I expect this to be quite straight forward to use. As for the more nuanced questions of how do I bind to certain events, I might be better off talking about those in another blog post.
In a sense there sort of is. If by DOM do you mean a method to structurally describe you application/views you are probably talking about the UI system called Storyboard. Storyboard is a WYSIWYG UI building system which allows you to describe the different elements of your application on individual pages, and even how they connect together. So in some sense this is like writing web pages and creating hyper text references between them.
Again, there does in fact seem to be a way to achieve this. By CSS I’m probably referencing to a means by which to have fine grained control over styling/theme of my application. There is an API infrastructure called UIAppearance that seems to allow me to have a centralized location for you different application styling configuration.
There are even libraries that have emerged that build on this infrastructure and make it more abstract by allowing me to define my rules in JSON, and even something remarkably like CSS.
One of the other concerns of CSS is position. The technology that exists to handle that is probably auto layout. Auto layout is a layout constraint system built into Storyboard which seems to allow me to describe in general how I want various UI element to be position relative to the window size and other component. In effective this is how you achieve responsive applications that work on many different screen sizes.
I’m still at the beginning of my journey with iOS. I’ve bought a Mac Mini (which I will talk about in the future), I’m starting to get familiar with the infrastructure and architecture of the system and hoping over the coming weeks and months I’ll get to share all the ups and downs of my exploration of iOS.
The following links the various reference I used to write the article above. Any links I used throughout the article can be found here.
One of the key questions you might ask yourself before embarking on doing an audit of your code is, what is the point? Well in my view things like copy/paste programming are a code smell that indicate deeper issues. Why are programmers copying code rather than reusing for instance? Do they lack the skill or knowledge to do proper code sharing? Do you need to invest in training? Perhaps you are missing some sort of design layer and this is the only way programmers have found to cope? Perhaps your team is too rushed to do proper design and you might being running head long into big problems in the medium to long term?
Ultimately, for me that old expression “information is power” really captures it. A business wouldn’t go long periods without auditing their finances, or measuring the sales performance of their sales staff. Even the idea of evaluating employees is common places with quarterly/yearly reviews. Why don’t we scrutinize our code as keenly as business do their employees? The more data we have to hand the better decisions we can make, or at the very least we can see what decisions we are clearly not making.
First you needed the data. If you are using source control (please tell you are using source control…) then this process should be quite straight forward. I’m working on a project at the moment, it’s a small WordPress site and happen to have the WordPress source on my machine. So why don’t we have a look at that code base?
The version I’m using is hosted on Github so I’ll be using Git to handle getting the right code. I’ve done this analysis with SVN as the VCS in the past and it’s quite straight forward to get code out of that too. Either way you’ll want to loop over a range of some sort. In my script I’ve hard code tag version of the code base to check out but if you were checking out revision numbers or were thinking about incrementing a date a great bash command to do this is seq. This is a great little tool for producing a number output based on a few parameters, using that command with a for in loop you have an easy looped range to work with.
In my script I use a sub-shell to perform the checkout/update. There isn’t really any reason to not have jumped into the working directory once and stay there for the duration of the work, but I wanted to keep my files outside of the source code area I was analysing because I didn’t want anything to happen to those files when jumping between versions/tags.
1 2 3 4 5 6 |
|
1 2 3 4 5 6 |
|
With this WordPress analysis and other ones I’ve done I’ve needed the date to corresponding to the tag/revision I’m analysing. To do that my script used the following bash command. Relying on the assumption that we have just checked out the version of the code base we are about to look at. We gets the top commit from Git and grabs the grep the date and commit SHA.
1
|
|
In SVN you can do the same with svn info which presents information about your local working copy. If you grep the string “Last Changed Date:” then you should have just the line with your working copies last revision date on it. I’ve additional include the sed command that will remove the words “Last Changed Date:” to leave you with the pure date information.
1 2 |
|
CPDs mission statement is explained on it’s website.
"Duplicate code can be hard to find, especially in a large project. But PMD’s Copy/Paste Detector (CPD) can find it for you!".
And it is exceptionally good at doing just that. The great thing about the CPD tool is it tokenizes the language you are scanning and looks for duplication at that level. So any kind of difference in code formatting, comments, blank lines…etc do not throw it off. Renaming variables, method names or subtly changing an algorithm would thrown it out though so those lines will not show up in its output.
Once you have a snapshot in time of your code base you’ll be able to run the CPD tool across the code. Sometimes you might need to exclude certain directories for various reasons, such as not analysing 3rd party libraries or other parts of the code base that are not relevant. In the script I’ve included a “EXCLUDE_PATTERN” concept that allows you to exclude a directory in this way. It limited to excluding a single directory right now, but it’s easily extended.
There are a large array of languages that CPD supports. I usually like to try out the scanner a few times and inspected the kind of duplication it finds. In some JavaScript projects I’ve analysed I’ve felt 75 tokens was about right. But for WordPress/PHP it seems you’re best off ramping that up considerable. I’ve put the bar all the ways up to 200 tokens for this analysis.
The kind of graphs you can get out of this analysis are interesting. Here we can see the raw quantity of duplicated code seems quite large and is growing fairly rapidly in the WordPress code base. When you look at the raw data however you find that a lot of duplication that does show up is really just a few lines here and there. The kind of thing that is difficult to avoid or even pointless to address. The key thing is to check out a sample of what is reported by CPD and see for yourself whether this figure is really as bad as it seems.
Graphing the duplication versus the total amount of code is a better way to gauge things. To get the figures for the total amount of code in the system I use a tool called cloc. The type of things you can find with these figures are if duplication and code base are growing at the same rate relative to one another (which is what you’d expect/normally find) or maybe the rate of duplication is clearly getting out of hand? Finally with this tool you can get the data that allows you to calculate the percentage amount of duplication versus the overall code base.
Cloc is a great tool for giving you insight into the amount of different languages in a code base. What I like about it is when it parses the code it can calculate the number of blank lines, comments and then total amount of code. Instead of a plain you have 100 lines of code you can find out you have 60 lines of code with a bunch of comments and blank lines. This is useful information.
Here is a straight forward graph showing the growth of different languages over time. Obviously PHP was going to be winning out over everything else, and perhaps it’s not surprising to see that there is more CSS than there is JavaScript in the system. The really interesting thing for me is you can see that SASS is only really getting a foothold in the project and there doesn’t seem to be any big strides to move the CSS over to SASS at the moment.
Some of the silly thing you can do with this data is to reason about the future of the project. For instance here you can see then number of languages that make up the source code and a graph projecting potential for new one over time. If these numbers are anything to go by WordPress will consist of 8 different languages by about 2026 :P.
I’ve had this script kicking for a little while and recently I added something to it called top ten files. The basic idea is I can get an output of the top ten largest files (this is based on raw number of lines). The length of files can be a code smell like anything else and I figure it was an interested figure to graph either way. In the case of WordPress you can see that the size of the top ten files are increasing with each version, but are roughly the same length, except for one outlier in version 3.0.
Here is the full script, warts and all. There is plenty of issues with it, but it was something I put together in a few minutes, so I’m not super concerned by it’s quality. There are few main components of the script;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 |
|
Inside of Excel I used a few basic formulas after I got all of my data into it.
First, since I had my columns of data about duplicated code I wanted the number of lines of code that could theoretically be deleted or at least redesigned properly. When duplicate lines are being presented in CPDs output; it displays the chunk of code and all the places it shows up. This includes the location of the single representation that you potentially want to keep. No problem if you account for that in your formula.
1 2 3 4 |
|
Once you have a column of these figures you can sum up all those totals and have an overall total amount of lines (per version/revision) that might need immediate attention.
When you do this analysis a few times you start to loath scrolling. Some of the data sets I end up with are 15K+ lines long (when you concatenate them all together). That’s a lot of scrolling, so when I output my data I make sure to measure the size of the data so I have a series of offsets for each file. Then using Excels “INDIRECT” function I can do a SUM on a range of data without having to scroll up and down on it.
1 2 3 4 5 |
|
With this formula I am able to SUM big chunks of an Excel file without having to scroll. I just need to calculate the start and end position of each set of data which is easily done using the offset data I collecting during analysis of the source code.
If you have the total amount of code in your system and the total duplication it’s natural to want the percentage duplication as well. With some basic math we get a value that represents 1% of the total overall code in the code base and then we divide that figure into the number of detected duplicate lines of code. Now you have the percent duplicated lines of code in your system.
1 2 3 4 |
|
In past analyses I sometimes end up with a number of piece of data starting at different points in time. At first you’d think this should be easy to graph, just grab the series of data and Excel will figure it out. But that can result in weird incorrect graphs where everything start at the same time. The way to handle this situation is to look at/arrange your data properly. I didn’t figure this out on my own, I landed on a blog post by an author called Jon Peltier who gives a good step by step guide.
The basic thrust of the articles says that the graph component is very smart when it comes to dates, but you have to organise your data in a certain way for it to figure things out. So if you have two or more stacks of data starting at different points in time arrange the like so.
Your dates will all be in column (A) and your corresponding data in the other (three in my example) columns. When you go to graph the data you have something pretty decent. The only trouble then is gaps.
To get over this right click on the graph and you should get the option “Select Data” (Excel 2013 anyway) and on this new modal you’ll have a button with “Hidden and Empty Cells” which allows you set the behaviour for data with gaps that appear in the set. Choosing “Connect data points with lines” should help resolve the broken graphed data.
After doing this analyse I was curious as to other approaches I could of taken. I did a bit of Googling and found some interesting possible tools that could of helped me do this even quicker.
CSVKit is a great tool for working with CSV files at the command line. The work I did in excel for calculating the number of duplicate lines could of been calculated using this. I might of just ended up with a smaller set of figures and less work in the Excel document overall.
I recently tried StatSvn against a code base I’ve been working on, but found that it was very slow and eventually exploded in the process. Because of the central nature of SVN, network traffic and load on the server can have an effect on your ability to get the log data StatSvn needs. The last time I used this tool I had tried to index and analyse everything in the repository (which was very, very large) which would explain why it would of fallen over. If you are using it on a very large code base, it’s probably best to get it to work on a subsection of your code base rather than the whole thing like I did.
Sometimes you are in a position where it doesn’t really make sense to have to invest in a big tool/infrastructure or large amount of time to analysis your source code. A side project for instance. Much of the time gathering a little data can get you 90% of the value a bit system like SonarQube could. But sometimes you do need those system and when you do, you should absolutely set them up.
The advantage of sitting down and dealing with numbers in this kind of primitive way is it gives you a sense of your code base, it makes you curious and want to find more involved and interesting figures.
If you’d like to see some of that data I used to create my graph above, feel free to download it and inspect it for yourself.
After a good bit of thought I figured it might be helpful to break the question down further. Documentation is something that is shared between all the stakeholders of a project. Those could be programmers, “Product Owners”, requirement engineers, architects, project managers, CTOs, CIOs software division heads. They could also be other departments like Q/A, marketing, localization, services/support and release/delivery.
Given the breath of people who are affected by these assets it would seems important to decided on the right tools and process for handling this information. What’s important then is establishing what your priorities are.
My personal experience with this is keeping high level and low design documentation in a Git repository. The solution at the time was a Rakefile (Rake is a Ruby version of the make build system) that was designed to pick up the project docs (written in markdown) and recreates the directory structure in an output folder and renders all the files into a HTML within this output folder. Things got messy when there were images and other assets that needed to come along for the ride and linking between documents was a bit of a nightmare. We used Jenkins to build software, so each build we’d create our docs which we could get at them through a URL, but we had massive problems with that later when our Jenkins set up changed slightly (all our URL got messed up).
We went through a variety of issues with the docs, such as getting access to them for editing, because you’d have to get access to repository. You’d sometimes end up in situations where’d have to merge them (which wasn’t that bad), but mostly people weren’t happy with markdown partly because we were using the Kramdown rendering engine and all the side by side rendered markdown editors didn’t use that renderer and the document they were working on didn’t render the same on our servers because we had custom CSS.
If I had to assess the way we did those documents on that project I would say it sort of worked but needed a lot of attention to get all the issues ironed out (which didn’t happened while I was there).
Measuring up that set-up with the goals above:
I started to think about the problem and reasoned what might help would be using something other than straight Ruby and Kramdown to produce the rendered output and something other than Jenkins for serving the documentation. The following is a list of projects that seemed promising.
You can see that I was leaning towards Wiki’s and even a full on Git web interface. I think I was beginning to understand and see all of the different goals and needs of a good documentation system and that is the reason I was doing that.
As I studied the options more and more I realised why it is difficult to use your own code RCS for your docs. Keeping your docs besides your code base made it difficult for other team member to create or contribute to them. The tools for writing the documents were also quite alien to them. People are used to using things like Word or even MediaWiki for creates documents. They don’t really know markdown, git, svn…etc and definitely don’t want to use Notepad (lets face it, we’ll tell them to use Notepad++ or Sublime Text all we want. It’s just not important to them).
The success stories of docs beside code are usually open source project. One of the main reason I believe this is the case is ease of use. Open source projects are usually about the code. Documentation is something that helps to explain the design and provides examples. If there is an API then documentation explains how to use it, some of the documents will be partly (or entirely) generated from the code itself. So in that case the primary concerns is around collaborating between the different programmers working on the code base.
The trouble is, in an ordinary work place the main aim of documents are around collaborating of the technical, less technical and non-technical staff.
Microsoft Office rules the commercial world. Many people are very familiar with it and know how to use Microsoft Word. Which is probably why you will often find most documentation being written using that tool. Given that you’ll often find Word + SVN/Sharepoint as a fairly common pattern in the commercial software world. There are probably plenty of examples of places that just have a bunch of Word documents on a network drive (this is just plain bad because of traceability).
These kind of approaches is great, and Word has come a long way over the years. You can even add annotations and in-line comments to documents (not in real-time as far as I know). The trouble is Git doesn’t version binaries files very well. I know that SVN does have ways of working with Word documents, that is why you often see the two together, but we were using Git so Word didn’t make sense.
In the end, I don’t think our experiment with keeping docs next to code worked very well. Keeping, accessing and using the documents that were kept in source was too difficult. Having a better system on-top of those docs like the list I enumerated above probably would have gone a long way to solve that problem, but I’m not sure. My advice would be that you should be careful about that decision, it could turn out to be more trouble than it’s worth.
As the user bstpierre noted in the Stackoverflow question, “What Part of Your Project Should be in Source Code Control?”:
"Project documentation is cumbersome to maintain in a source control system. Project docs are always ahead of the code itself, and it's not uncommon to be working on documentation for the next version while working on code for the current version. Especially if all your project docs are binary docs that you can't diff or merge."
Below are a series of articles and tools you might find useful when deciding to take on this challenge.
Say you are tasked with developing a feature. It’s pretty big and could, by your estimates, take anywhere from 5 to 6 weeks. At this point you make a calculated decision (more on this later) to take a short-cut and get the feature out in 2 weeks. Those 3 or so weeks would be considered technical debt.
To put it in simple terms. Technical debt is any decision (inadvertent or deliberate) that results in a lower quality code base, or more importantly in making it harder to maintain the code base and build future features. When you take a short cut everyone who has to interact with that short cut takes a hit on productivity in either understanding or usability, that is the interest payment if you will.
For a more thorough explanation it would probably be worth hearing what the man who conceived the metaphor thinks, the following video is pretty short at 4:44 so have a watch/listen.
The main take away from the video for me is the need to manage and understand debt. The trouble I’ve seen in my career to date is with the inadvertent type of debt that projects usually end up with.
When Ward conceived the debt metaphor it was a way of explaining to his managers and to the business people who he worked with why one would conduct a refactor to a code base. A code base/module that for all intents and purposes worked, was fine and probably even now in use in the field. To Ward it was about putting back the understanding/learning you gained from the process of building the product.
It’s clear from that explanation that Ward is a conscientious and professional programmer. Given that it would seem to me that he is probably going to have design and risk management at the forefront of his mind. For a lot of developers out there it might feel like that’s not the case where they work. Martin explores the metaphor a bit more thoroughly for rest of us.
The main element of Martins musings is the concept of the Debt Quadrant.
I think this keenly describes what is felt in most projects. Martins career and writings are based mainly on the principals that design is good and helps you to move faster. And that is what he explores here.
What is interesting about Martins quadrant is where certain concepts fall. Does the idea of “move fast break things” lay in deliberate & reckless or deliberate & prudent? What about if you solved a design problem with a lot of inheritance where a visitor pattern would of been more appropriate? Were you being reckless by not being fully versed in all the design tools you needed? Is there a base level of design you should of had before being given the helm of that project?
The main distinction is probably what you do after you ship. In my view a “prudent” decision becomes a “reckless” one when you don’t face or even admit consequences. Lets say you make that decision to knock three weeks off the schedule. Where have you tracked that decision? Have you informed your team mates or colleagues about that decisions? If you have a bug/task database has you logged that decision to be addressed at a later date?
Thankfully in my life I have not had to have the burden of a lot of financial debt. I live in Ireland; we have “free” education which come with some costs though nothing like North America and elsewhere. As such I’m a touch adverse to the idea of debt. I save up to buy things like cars, televisions…etc where many people use loans and financing options. I have values by which I live my life. I’m a bit different to most people.
Given this I am trying to understand the need and point of debt. Debt is a tool and like any tool when used correctly it can allow you to do things you could never achieve without it. But like a tool it can very easily turn into a deadly weapon. One of the main causes of business failures is cash flow, guess what can impact cash flow? That’s right loan repayments.
Steve McConnell is a very smart guy and once said:
"I think there is some non-zero amount of technical debt that is okay from a business point of view for the project to take on."
This is a tough pill to shallow for most programmers and Steve even had a potential explanation for this perspective:
"A lot technical staff have been burnt by implicit debt often enough that they have gravitated towards to the position that the only good amount of debt is zero"
And once again I think this comes down to what ones perspective is on their work. Firstly are you explicit about the decisions you are making? And are you explicit about the short cut you are taking? Finally have you got enough confidence and more importantly professionalism to fight for the need to fix this short cuts at a later date. Obviously if it makes sense to fix those short cuts. But there again is the point, deliberateness.
Some of the more generally agreed upon examples of technical debt are:
There is a bit of debate about this point. Some professional out there, such as Bob Martin, would be inclined to think that a mess is not debt. What Uncle Bob means by “a mess” in this context is unprofessional practises like poorly formatted code, badly named variables, badly written comments…etc. To Bob these are down to laziness, they are not decision taken with the aim of achieve anything in particular.
"The more technical debt you take on, the tighter your disciplines need to be. You should do more testing, and more pairing and more refactoring. Technical debt is not a license to make a mess. Technical debt creates the need for even greater cleanliness."
And on reflection I suppose I’d have to agree with him. I listen to a great podcast by a very experienced entrepreneur Sean McCabe. He is a part of the design industry. The whole point and purpose of his podcast is about bringing more professionalism to his industry. He’s a hand letter and given that premise you’d think there wouldn’t be that much to learn. You would be wrong to think that. In particular there is one thing that Sean says a lot about designers and artists a lot. He talks about the situation where someone ends up with awkward clients and they lament it. What Sean says about this situation is, “There’s no such thing as clients from hell because only designers from hell take on those type of clients”.
I think Uncle Bobs perspective of debt and a mess is coming from the same place. So to paraphrase Sean:
There are no code bases from hell just programmers from hell who would choose to work on those code bases
To be completely frank. I’m not sure. I’ve been reading a lot about this topic in preparation for writing this post and it would seem there are a variety of good options, all with their pluses and minuses.
There is a great article by David Laribee called Code Cleanup - Using Agile Techniques to Pay Back Technical Debt. In this article he talks about using a system thinking process called Theory of Constraints (ToC) which was developed by Eliyahu Goldratt. The idea behind it seems to be identifying bottle necks and some degree of root cause analysis. It certainly seems like an idea I will be looking into in the future.
A few presentations I watched talked about using Scrumm and Agile development methodologies to help manage and track debt. In these development system you are talking about what you are doing at a very fine grained interval (daily stand ups), perhaps even pair programming. In Scrumm you might make a story or task which you would estimate when taking on debt. After a time you re-estimate you backlog items you get to find out if your debt is going up or down, and if you are monitoring velocity you can perhaps correlate those decisions against those value too.
Other means of measuring debt would include using tools like Sonar to track metrics like cyclomatic complexity. Though it generally consider a good idea to reduce values such as cyclomatic complexity it is dangerous to have people focus on numbers. Metrics are a powerful tool, but in the wrong hands or just used incorrectly can do more damage than good. Just look at what happened with most justice systems around the world. Many countries are coming around to the dangers of metrics in their police forces, the health care system, their schools. Should the business and engineering world pay attention as well?
I’m not an expert by any means. I have an Internet connection and an interest. From what I can tell they type of things that would be worth doing might be:
If the above seems potentially overwhelming and perhaps you are worry about the cost it will have on your productivity it might be worth considering this perspective from David Simner.
"Instead of looking at the entire application and looking at metrics over it, you basically just look at what you're going to have to change. Because some bits of the application are just going to sit there and not have to change. More interesting is the bits you are going to have to change and how those bits affect technical debt."
There are a lot of intertwining issues when it comes to using the debt metaphor. It’s first and foremost role is to help you as a programmer find a way of talking to business staff. The language we use as engineers is alien to them. We need a common vernacular. Debt is way of talking about technical decisions that a lot of people can understand. Much more common and in reach than talking about “refactoring” a “clean code”. One of the biggest problems for me in my career is communication and developing my “soft skills”. Ultimately programming is about people. We are making tools for people with people. Finding novel ways of thinking and talking about problems is what separates programmers from professionals.
Below are a series of articles and videos I used to research this topic. You might find it interesting to dive into them and get a deeper/better sense of this topic yourself.
If you’re reading this and know about continuous integration, then you are either convinced and using it or are on the fence. I want to help push you off that proviberal fence or put you on it if you are on the “wrong side”. Before I continue let me congratulate you on making the leap to automating your build system. Lets not even talk about those people that still do that manually! If you have Task Scheduler or Cron doing your build work then you probably have a command line build system. You’re on the right track!
My first question then is does the following look familiar?
Odds are you have to set-up those machines manually? Odds are you have to configure the tasks manually? Odds are you are probably only doing a nightly build at best? Odds are you have those machines are sitting ideal for a long periods of time? Odds are you are not able to monitor the execution of the processes on those machines dynamically as they run?
Let me ask you a few questions about your setup.
If you are using Cron, and you have a large product you building I can probably guess the answer to these. If you’ve make you build scripts graceful enough they’ll send you an email. In fact if you have a few machines running you get a lot of emails. You’ll probably send that to a mailing list that lots of people are signed up to. Most of those people will have an email filter set up to stash them away or even delete them. Turns out if you spam your developers with build emails they will ignore them.
On a failure you might frantically log into all you build sever to read the logs, and then you might manually kick off you’re builds.
To change the interval you might need to log into a heap of machines and change crontabs or jump into Task Scheduler. Odds are, even if you know you need to have more frequent builds you’ll never bother because it’s a hassle.
If you builds take a long time, you wouldn’t even dream of setting up more than one per build server… if you have a lot of branches you probably have a server per branch. If you don’t have that many machine you’ll probably have some builds happen a few times a week, then others on alterating days. And that results in a long lead time between development changes and testing, acceptance and releasing.
Here are a set of goals you should shot for:
You cannot easily achieve all of these goals with Cron or Task Scheduler. You shouldn’t try, because those are not the right tools to use to accomplish this epic set of requirements. So the question is…
What I describe in the previous section was a continuous integration (CI) server. Something like Hudson, Jenkins, Cruise Control…etc. To quote Jenkins, a continuous integration server is an “application that monitors executions of repeated jobs, such as building a software project”. That quote really does not fully convey the power of using a CI server. All of those goals I describe previously can be accomplished by using one of these systems and by having granular build script steps.
Lets take the first point, “making the most of the server”. Because these CI understand Source Control, as you make changes to the code base they can pull that code down and do things with it. CIs can react, they are dynamic. Surely that’s all I need to say to sell this to you, but let me continue.
What about building your software with a single command. Well, you should have that sorted with your build scripts, the makes, rake, grunts of the world. All a CI server will do is kick those off and monitor them. But here is the interesting part, CIs monitor the output of your system. They grab the STDOUT of the process they are running and can reason about it. They provide a web front-end for your build logs. No more do you have to jump from one machine to another to find out what’s been going on with your builds. The more data you split out of your build process, running tests that produce an output, running code coverage that processes an output, running static analysers or linters that produce an output, all of that is captured and processed by these tools.
You really don’t know how life changing that is until you experience it. I know I sound like I’m over egging it, but it really does change everything. You have a dashboard for everything that happens with your software, these systems integrate with Intranet software, they have APIs to grab data and stick that data on TVs/Dashboards if you wish! CI servers integrate with your bug tracking software so you can find out exactly when a piece of code checked in is built and ready to be Q/A or whatever your process is.
The CI software handles things like checking out code, emailing, managing processes…etc you now no longer need to put that stuff in your make, rake, grunt build systems. You’ve reduce the amount of code you have to deal there. Less code means less complexity, means less bugs/problems. It’s a win-win.
CI software systems integrate with the vast majority of bug tracking software, have API and plugin infrastructures that allow you to write whatever you want. You more than likely only need to search for a plugin and you have an incredibly complex feature straight away, no work. You focus on things you actually care about.
While talking about these CI servers at my current workplace I brought up one of the most important benefits of this technology. Imagine if you will, you have multiple build servers. They all have their own independent setup and need to build different branches/versions of your code. How does CI software help you manage all the data that will come out of each? Do I have to go to multiple dashboards to see what going on?
Tools like Jenkins provide a sophisticated master slave architecture. In this system you have a single Jenkins instance at the top which manages all build related work and captures and displays all the data for that work carried out… on the slave servers you can have another instance of Jenkins which broadcasts it’s wiliness and ability to build software. The master then coordinates all of the slaves, gets them to do their building and then captures all of their output.
You get all of your data for every build in ones place, you get to see the build progress of these different environments. You have visibility into your multiple build server based build system set-up. It’s incredible. What is better is since they are CI instances they can set them up to quote builds. You can get the maximum benefit out of every machine, having it run the maximum amount of builds possible in any 24 hour period without the possibility of corruptions.
I have listed some compelling reason why I think a continuous integration server is a much better option than Cron or Task Scheduler for your software products. Now it’s up to you if you want to use one. These kind build engineering tools and practises are becoming standard in our industry and I think it’s time to take notice. Someone smarter than I once said:
the build server is critical-- it's the heart monitor of your software project.
I think this is more true now than it was in 2006. So go forth and get rid of those scheduled jobs and get some new found peace of mind while you are at it!
Below is a list of links that used to research this topic. I’ve place them here for your convenience and so you can go double check the information I’ve given you if you would like.
There are loads of CI servers out there, you don’t need me to tell you which one to use. That’s up to you. I’ve listed a few options throughout this article here is neat list of those for your reference.
The following are articles I used as reference points in this post. I’d highly recommend watching some of the Etsy video, they are very inspirational because once you go past just using CI servers you find out what it takes to ship your product multiple times a day.
Here are few miscellaneous links, articles and software. The most useful of which is probably the Shopify’s Dashing framework.
The build system I updated recently was a Grunt system for a web front-end. Previously it had been been a bit of an odd structure:
Other problems with the build system included:
First let me explain the structure. Each part of the build system was a whole self contained Grunt build system. In fact there was a fair bit of copy/pasta going on here. So it volatilized the DRY principal to an extreme extent. Given that they were individual build systems it would mean you’d have to do an npm install in several different directories and some of the plugins/dependency would have to be downloaded in multiple places and the package.jsons had gone out of sync, meaning some of the build system depended on new versions of certain plugins. Clearly a bit of a disaster.
It was time to clean things up.
My task was to merge all of the different grunt files and package.jsons into one place. I started with the package.jsons, which seemed like an easy enough job. I reasoned that there would be no adverse affects to getting the build system to converge on the latest version of each of the plugin. I was correct and was able to get a workable package.json fairly quickly.
I knew looking at the different grunt files that merging those into a single file right away would be a bad idea. So I researched a few plugins which would help me split the contents up a bit. I found a couple of great articles on managing grunt build system and the two plugins that stood out from that research were:
Load-grunt-config is a great plugin. It is a nice little piece of work created by [Anatoliy Syernyi][asyernyigithub] which handles the loading of plugins configurations and tasks for you. This allowed me to create a whole new file structure that looks something like this:
Let me explain the structure. Now there was a single entry point for the build system, one single Gruntfile. One single package.json. Now one npm install was required to set everything up. All the different plugins the build uses belong there, as for the individual tasks, they would be defined in a file of there own under tasks. This looked like over kill at first, but eventually you have very specific handler routines and configuration for some tasks which it would make sense to encapsulate in a single location. I also include a special utils area where shared functionality would live (helpers.js) and derived project paths (globalSettings.json).
The major and important element of this restructure was the devSettings.json.sample file. This is a special configuration file that would sit on each developers machine and when renamed to devSettings.json would allow them to have their own local file paths/and overrides for the various build settings. The file devSettings.json was made to be ignored by the source control system meaning there was no chance of it accidentally getting checked back in.
I got this to work by using the postProcess handler method that load-grunt-config exposes which passes you the an object instance of the package.json file content. Here you can use a plugin like deep-extend to merge those package.json settings with your own personal overrides, which is what I did.
One of the upsides of using load-grunt-config was it allowed me to use a plugin called jit-grunt. This plugin reports to be able to have a build system where:
“Load time of Grunt does not slow down even if there are many plugins.”
This sounds great and I used it right out of the box. I don’t think the amount of plugins that are there currently are causing that much of an issue, but I know I want developers to use the build system as a part of their daily work flow and that the run speed was going to be an issue so I decided to be proactive. Anyway, it was only 3 lines of code to active it.
One of the downsides of load-grunt-config is it depends on somewhat of a defacto naming pattern for plugin tasks and their npm names. This can fall down quite easily, I encounter this with two plugin in this build system:
In the end I had to sully the main grunt file with two grunt.loadNpmTasks which annoyed me greatly.
One catch with using jit-grunt is because it does not load tasks into the namespaces until they are explicitly called; then running grunt –help and grunt –version –verbose no longer worked properly. As a result I am currently unable to do any kind of bash autocompletion of the tasks for my newly cleaned up build system :(. There might be a way to get it back, I’ve put in a github ticket against grunt-cli to see what those guys think of my issue.
The previous build system was lacking on the logging front. If something went wrong it would typically get swallowed, which is a pain because being able to understand what went wrong and how long it might take to fix it is important. Throughout this restructure and rewrite process I took the trouble of using grunt.log, grunt.fail.warn and grunt.fail.fatal where appropriate.
I also made sure to include an extra command line flag, –debug, so our email reports wouldn’t be drowned in debug details.
Using this set up I was able to create a build system was:
I moved jobs recently. Previously I had been using web technologies to create an application visualization development environment, a bit of a mouthful. The application was a form of website builders which is the simplest description I’ve been able to come up with. Using web technologies meant JavaScript and the place where I was working felt it might be a bit of a risky technology to use. The reasons from where firstly, JavaScript being an interpreted language meant that it was an inherently unsafe, in the sense that you’d have to wait till runtime for things to blow up, language. The other primary driver (look at me going all business-speak) was the very large gap between JavaScript and Java (the main development language in the rest of the company) meaning you might not be as easily able to use programmers from other teams on this new one. Plus tooling, development environments, documentation…etc.
A decision was made, and I ended up with two years+ worth of TypeScript experience.
TLDR: It took me a long time to warm up to it, but TypeScript turned out to be a great tool, jump to the conclusion to find out more.
TypeScript lets you write JavaScript the way you really want to. TypeScript is a typed superset of JavaScript that compiles to plain JavaScript. Any browser. Any host. Any OS. Open Source.
TypeScript give you Ecma 6 features today. It’s a transpiler that takes Ecma 6 syntax and various additional TypeScript features and turns them into valid Ecma 5 or Ecma 3 code. The good people over at Microsoft have been working very hard on achieving this and have done a fantastic job so far. On top of that you get something that is not present in Ecma 6, type safety. Type safety is of course a very contentious issue. I’d be surprised if the average programmer hasn’t been witness to, or been part of, the great debate of static versus dynamic typing. I never really had strong feelings either way, I just had a general unease with the clunkiness of Java’s type system versus the elegance and succinctness of languages such as Python and Ruby. To be honest I think most of the debate around static versus dynamic is probably Java’s fault, a view I’ve seen kicking for a while.
The genius of TypeScript is the fact that the type system is optional. You can happily use TypeScript for its other features, such as; its class syntax, the module system and other types of inferred type checking without ever breaking out explicit: “number”, “boolean”, “string”, “Object”, “Event”, “any”…etc
Some of the following “good parts” I must admit are a bit tenuous. There are plenty of features in TypeScript that you could of gotten from the likes of CoffeeScript (initially at least, TypeScript’s feature list keep growing though). For instance if all you wanted was JavaScript with a slightly nicer syntax and something to handle chunky code around closures, you would be better off with CoffeeScript.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
|
I’m not going to go into a full feature list. But as you can see the above style of syntax is the kind of thing you’d expect from an OOP language. One of the main developers of the language was Anders Hejlsberg, who is the chief designer of the C# development language and .NET framework. So it coming from an excellent pedagogy.
As you can see from the code snippet, there is a class syntax which is cleaner and more recognizably traditional OOP development languages like C# and Java. Under the hood the code that is generated is essentially the usual prototypical inheritance system you’d expect.
Naturally for an OOP language it has interfaces, public/private methods and class attributes.
Finally, for me one of the great features of TypeScript is its syntax, for the most part, does what you’d expect. You don’t need to worry about the context of “this” so much. Using the “fat arrow” Ecma 6 syntax (which original came from CoffeeScript) you can get around a lot of messy closure issues.
1 2 3 4 5 6 |
|
Imagine a world where you didn’t need to check every parameter into a method for “nil” state? Great isn’t it? Well with a complication step you express your desire for a method to never be called without some parameter and then the compile makes it so.
Now that isn’t the whole story, but it pretty much captures it. TypeScript (and generally anything that isn’t plain old JavaScript) gives you extra tools of expression and puts rules in place to make sure your intentions are respected. Surely that can’t be so bad?
Having an outline of an API of libraries was a godsend. No longer did you need to know a library inside out before being able to use it effectively. In fact I would say that would be one of JavaScripts major issue, there is only so much context and code you can hold in your mind at one time (that is the case for me anyway) and the more things you have to juggle the slower you will go.
Now that isn’t the whole story, but let me save that for the Bad Parts below.
As I mentioned above, TypeScript gives you a few more syntax tools to allow you to express your intentions. As such you have a better idea about the intent of a method beyond just the name, you get types to go along with the input parameter names. You can see at a glance whether there is a return value and what type that is going to be. The pesky open ended “options” object now had a proper description of the keys and values and expect types of all of their possible contents. All very useful things. And of course the tools (that are really only showing up in the last year or so) allows you to generate decent dependency graphs…etc so you can plan refactors and see hotspots pretty quickly.
Since there is a much richer source code to draw from documentation generation should becomes a lot easier. In the case of JSDocs, you have to keep those comment sections in sync with the code section and since there is nothing to properly enforce that relationship things go out of sync quickly and the comment become a lie. Ultimately I didn’t find any decent documentation generation tools for TypeScript, I tried getting a TSDoc style system up and running but with little success.
As yes, and after all that positively comes the pain.
The primary reason we went with TypeScript was “tooling” which is hilarious when you consider we took it up when it was [v0.8]. The only tooling that existed was Visual Studio, which at the time we couldn’t get to work for us. At that stage Visual Studio and TypeScript needed to be taken up at the same time, we had begun writing TypeScript code before then. We didn’t have a huge code base but it was big enough for someone to say, screw it, when it didn’t instantly work. When I was leaving the team was looking at Webstorm which looks like a fantastic tool and would be a major boon to anyone looking at development environments for any kind of web development.
The reason VS didn’t work for us was because of the “reference” paths. For the compiler to be able stitch things together properly you’d have to include a reference to the paths of other files that it needed (later we found the “reference file” method to be easier and more maintainable). For some reason I think that screwed with VS and it probably didn’t help that we had separate modules going and we weren’t using VS to build our code.
Obviously though, that was not the languages fault.
Source maps, though they sound like a nice idea are a nightmare. The technology was made in hell and deserves to burn there, forever.
Hyperbola out of the way, the experience in Chrome, which was the main browser I was debugging in, was terrible. Not initially though, initially it was great. Even having the Sublime Text style “Ctrl+P” open a file with fuzzy search was brilliant. The problem was when you placed breakpoints and subsequently edited your code. This is where things went to hell. I never quite figure out the set of steps to reproduce it (to be honest I turn off Sourcemaps pretty quickly) but when you had break points and were refreshing the page after doing an edit you could find yourself debugging code out of sync with the new edits. Sometimes I found I was looking at a piece of code that wasn’t the code I thought I was debugging and wondering what in the hell was going on, why were some things nil when they should have a value. All manner of strange things would happen with Sourcemaps and me (other develops never seem to run into issues) so I had to give up on them.
Obviously though, that was not the languages fault.
Handing over a substantial amount of your code (the generated and manage inheritance system for instance) to TypeScript has some trade offs. For one, it depended on the library makers to be sane individual and to not do weird JavaScripty things (read normal JavaScripty things) when enhancing some core library you depended on. For instance I found myself integrating a few third party Backbone plugins, with Backbone and the code we had written for TypeScript. At the time I could not get TypeScript to agree with what was happening to it. I’m pretty sure the code would of run if I tried it in the browser, but the compiler freaked out so I just left it be.
Integrating with third party libraries has a tendency to be a pain in any language at times. I found it to be more so with TypeScript. Now if the library was written in TypeScript then that’s a different story, but 99% of libraries for the web were written in JavaScript so…
You know that thing I said about “you need to know a library inside out before being able to use it” and how TypeScript/DefinitelyTyped solved that, yeah only kinda. First off the bat, not all the libraries are there. Lot of them are, I grant you that, but not all of the ones you might need (for instance there is lots of Angular and very little Backbone). If you need a library that is not a part of that repo, then tough luck, go write your own. Which if you have to do that and are under time constraints can be kind of tough.
There are a few issues in a real production application that you have to account for when using a library. You want to make sure not to be too quick to update libraries, sometimes things change pretty radically (it’s usually okay if they use semantic versioning). That radically different stuff might mean you can’t upgrade right now. That’s an issue.
Sometimes DefinitelyTyped definitions can be written badly. It’s just a fact of life that a piece of code can be written badly, this is a community project after all. These people aren’t doing this for money, it’s on their spare time. With that in mind it makes sense to keep up to date with a d.ts because I’ve seen bugs from a d.ts having an “any” where it should have a more solid type and engineers wasted a bunch of time wondering why in the hell the compiler didn’t catch something.
Sometimes you can’t move up compiler version, that can be an issue if someone in the community re-write huge swatches of a d.ts to use some new compiler feature (which is the correct thing to do in my view).
So you have a few vectors… the third party library version can increment, the d.ts version can increment at its own pace as well, the compiler version can increment too. Frankly it was a nightmare to manage and keep an eye on it. What would be needed would be a package management system for those DefinitelyTyped files, which does exist now, but that is still in its early days. Frankly it would of been better for the TypeScript team to weight in on the design and production of those kind of support systems because it was sorely lacking during my time with the language.
Having a build system was a problem, for reason you’d think of and reasons you wouldn’t.
From a pure JavaScripty development style it means there is an extra step between you and the result of what you’ve written, though I think that is an okay thing. Putting the breaks on can help in a design and logic process. It makes you a better engineer to tease things out instead of just throwing code at a wall and seeing what sticks. However, after a while the compile step becomes pretty heavy (20 -30 seconds).
Now frankly that could of been our fault. We may have not been taken full advantage of the module system, or were using it incorrectly. When I was there we had three modules with about 30kloc~. Not massive when you consider TouchDevelop looks to be in or around 160kloc~. I’m not sure what we were doing wrong but I found development to be slower even then what I had experienced with Java.
The other issue with that was we had to re-compile our whole code base when any file (TypeScript) changed. I reckon if the compiler allowed you to compile individual files yet somehow was still able to figure out how to stitch them together without having to consume and read the whole code base again, that would produce an enormous build performance improvement. But that is just speculation. I’m sure the builds could be acceptable if it we had the right type of modules/build setup.
My single biggest issue with TypeScript is that it produces artifacts even when the compiler booms out and blows up with errors about your crappy (mine in this case) source code. The worst thing was since we had this kind of cascading build system (we used rake and task dependencies) it would find these artefact’s on a second build and then just assume everything was find. That I see as an genuine issue with the compiler. But I’m sure it’s probably a feature not a bug.
In the end, despite the warts, despites the complexity I enjoyed working with TypeScript. TypeScript or transpiled languages make a lot of sense for large scale JavaScript application development. JavaScript is great with a small team, it’s great for making things at the 10k lines of code, but once you start hitting seriously big teams and LOC you see in enterprise code bases you need the extra expression. You need the types. You need the structure.
The biggest disappointment was the Chrome debugging. I ended up having to debug in JavaScript all the time if I want to have consistent and reliably experience. The tooling in general made things very hard. IDE weren’t reliable for a long time, plugins for editors like Sublime Text only went so far. Additional tooling like documentation generation was fragile and didn’t work without breaking your back (I broke my back and it still didn’t work). The tooling situation has changed and improved massively in the mean time, but I’m talking about my experience, so.
I found there was a great deal of verbosity in the code I was writing. I don’t blame the language for that, more and more features appeared (even long before I left my last job) that was going to make the code we had written far simpler, it just we didn’t have time to look at upgrading the compiler right then.
Ultimately the root cause to all of my pain with TypeScript was that we adopted it too early. It was too early for good tools, any tools. It was too early for the community, it was too early to find out what would be the best set of “best practices”. We spent a lot of time wrangling with technology instead of writing the tool we were building. But that is the nature of being on the bleeding edge and having gone through that pain the project was in a better place and on a better trajectory as a result.
Ideally you’d never need to go there. The software you use and install would take care of all the details itself, but that is an ideal world, one we don’t live in. For me, it was Java. In the pre-Orcale days of Java whenever you installed the JDK on a new machine you’d end up in the WEVD. It was always a pain in the butt, but you’d look past it because you’d be in and out in moments (once you know what you needed to do). As a matter of fact, I’d like to take a moment to thank Orcale for creating the Java Control Panel and making sure to update the environment variables for when you are install the JDK on your machine.
Obviously there is more of an issue that would pertain to doing Java development without an IDE such as Eclipse or Netbeans. In college we weren’t encourage to use IDEs, so I didn’t. So I had to deal with these issues alot.
The main characteristics/flaws of the WEVD are:
I have been doing a bit of research on the environmental dialog because I have become somewhat obsessed with this little corner of the Windows world. From what I can tell the dialog itself goes back to Windows NT, possibly closer to the late end of the 90’s. It wasn’t until NT was folded into the consumer version of Windows that it showed up in the every day users world (not that anyone really knew what they were doing with it back then, well me at least).
Right before that, Windows had the autoexec.bat file. This file and usage of it was much closer to the Unix philospy than what it would become. You had a plain text file you could edit and get your particular program or scripts/whatever to show up in your system path. You could edit this file with whatever you wanted e.g. notepad.
I presume the reason for the dialog was Windows shift to the registry model for storing OS and application level information on Windows. As such the dialog is an interface to the registry database. And what a woeful interface they ended up making. But it did the job. And it continues to do the same job… probably something like 17 years later. The WEVD has not changed in any significant way in roughly 17 years. 17 years.
Below I present to you every version of the WEVD in the last 15 years:
All of this is a bit unfair of me I suppose. A basic principal of Microsoft has always been, “good enough”. In truth the WEVD is “good enough”. And there are plenty of alteratives that can do the job much better job. I’ve been using a tool called RapidEE for quite a while now and it’s everything you’d hope for in an environment variable editor. I guess it’s just frustrating when you see it and makes you wonder how it’s possible from a software development point of view for a part of a software system to remain developmentally dorment for so long?
]]>Have you ever been in the following situation; where it has been 8 months since you worked on a piece of code, you have moved onto bigger and better things. Different features, a different project and horror of horrors you get an email saying someones has found a bug in your code. It was a reasonably complicated feature you worked on, it took a lot for you to get it to the state it was in, and perhaps it wasn’t as well unit tested as it should of been, or perhaps worst yet, it’s unit tested out the back end and every test is passing?
I’ve been in this kind of situation. I haven’t been working professionally as a software developer for that long, yet I have had it happen to me on at least 5 or 6 different occiasians. The first few times it was a bit of a disaster. Not because the issue was big, but it was a blow to my confidence. Lets move on from that though. As I got my hands on larger and larger features it was a much bigger deal. All that valuable information was stored in the far reaches of my brain and noone where else. When the last commit message to a piece of code has your name on it you better get ready.
This is why I take notes when I work. I take very meticulous notes in fact. Would it surprise to know that I can tell you what I was doing, in a reasonable amount of detail, for every single day of my professional software development career? I can tell you about defects I’ve worked on, how I felt about developing certain software features. The rational I choose when it came to certain decisions I made about certain features. Why I started something, but didn’t go back to it. Exactly when I learnt about a really useful feature of a framework I was working with. I can give you references to all manor of Stack Overflow questions and answers I’ve used during developing a feature or working on a defect.
I believe in writing everyday. I believe in this principal not to become a better writer and communicator (though that would be a side effect). I do it to cover my back. It’s the case that the software and documentation processes I follow are not detailed. Well… they are detailed from certain perspectives. But they are in fact not detailed from a personal perspective. Take anyone you work with, take a feature they have worked on. If there isn’t a sentence in a document describing why they choose to do (x) instead of (y), it’s likely they don’t remember and never will. I know that is the case for me when it came to college projects and the very early days of my career.
It’s also useful from a administrative perspective. Where I work I’m expected to fill out a monthly time sheet. I know when I was in or out sick, I know when I was working on features for one project versus another. I know whos time I took up and when. I know how many meetings I go to and what was discussed and decided there. This is highly valuable information for my employer. They can be sure I am billing the right projects for the right amount of time every month.
From time to time I’ve heard people talking about the value of “learning in the open”. Sometimes that is not possible. I could not blog about the intimate details of the technologies I deal with daily. It’s just not possible, because it’s all propriety technology. It is the IP of the company I work for not mine. As such the kind of details I am keeping, though they could never be used to engineer or reverse engineer any of their tools is still considered sensitive and I take a personal and professional responsibility in never revealing those details publicly.
I started doing meticulous note taking, in the way in which I do it today, back in 2008. While at college I had a lecturer who insisted we completing a weekly “Learning Journal” for his subject “Industrial Automation”. To be frank, it was a bit of a pain at the time. The questions were broad and required a great deal of effort to come up with adequate answers to complete them. The following were the different question heading we’d have to complete week to week:
But I’ll tell you right now, I can tell you more about his subject then any of the rest of the subjects from that time combined… and when it came to writing a final report, it was a breeze! The level of detail required from us, and the level of introspection around what we were learning would carve that knowledge deep into my synapses of your brain. And ultimately it was a fantastic resource.
I did a thought masters in the same college and had the same lecture for a project. Again, the learning journal was a requirement of my output. And once again it was an immense help when it came to understanding what I was working on (deep introspection) and a life saver when writing the final dissertation.
I have three tools in my arsenal when it comes to note taking:
I think digital notes are very important. Being able search, my brain as such, is a highly value ability. However, I do not have or bring a laptop or tablet with me into a meetings or when formulating ideas. I think that pen and paper are faster much more valuable when it comes to getting ideas out my head.
The note taking format that I use is a variation on the Cornell method.
It is basically identical to the Cornell system except I put the points/questions column on the right hand side instead of the left.
An important element of my note taking method and the one I recommend you adopt even if you don’t do any of the rest of what I describe in this article is to date and time stamp every page of writing you do. It’s a frustrating experience (for me at least) to go over older note and not know when I wrote them. I get a great sense of enjoyment seeing my progress as an engineer and developer from reviewing my notes, and not having those dates hampers my ability to do that effectively.
Once I finish working on an idea, or come out of a meeting I proceed to digitize my notes. I don’t go overboard. I usually just take the main points and tasks/summary and place them into my note taking application. RedNotebook is a desktop journalling tool. It allows me to write a daily log of everything I work on.
In the image there are the main parts of the application; on the left is the the date widget and the tag cloud. In the middle is the main note taking space (formatted in markdown) and on the right you can place tags (very useful for searching).
RedNotebook also supports pre-written blocks of text called templates (they are like code snippets) which you can throw into your current work day when ever you would like. This is a useful feature when it comes to putting notes around meetings into my log (I go to a lot of meetings). I usually tag each day with a high level view on what I’ve worked on then.
At the end of all of this I now have detailed hand written notes, with the most important information in RedNotebook… which is also acting as a form of indexing system for my hand written notes. So when someone comes knocking at my door asking about some feature I’ve worked on. I fire up RNB, start searching, find relevant details there and if not there I know what date to flick to in my binder full of notes.
I’ve gone to the trouble of doing a bit of graphing for this post. Above I’ve provided a graph with days versus number of words written. As you can see there is a lot of variation, and my average number of words written reflects on the amount of information that I keep. Granted some of it is boiler plate (personal meeting minutes, where I detail who attended and the like).
RedNotebook provides some basic statistical information namely the following table of data which is accurate for my journal as of the 11/December/2014.
Statistic Type | Data |
---|---|
Words | 106177 |
Distinct Words | 9442 |
Edited Days | 687 |
Letters | 663692 |
Days between first and last Entry | 978 |
Average number of Words | 154.55 |
Percentage of edited Days | 70.25% |
Ultimately what I am saying is, writing is good. Keeping notes is a rewarding and more importantly professional thing to do. And when a process is not extremely granular and you want to avoid “project lore” use a process to keep a track of that information. If you can make that public (within your company, Intranet blogs?) and if not, then maybe consider a personal system like I have.
]]>The fundamental premise of “Coder to Developer” is to provide a starting point or practical guide to becoming a well rounded Software Developer. To transcend the basic title of “Coder” and become someone who has a full understanding and command of the entire software development life cycle. Mike Gunderloy, following in the footsteps of authors such as Andy Hunt and Dave Thomas of The Pragmatic Programmer fame, tries to give an insight (opinionated but practical) into what has gone into making him the developer that he is today.
Before I go onto to tell you what I thought of this book and what you might get out of it. Let me just tell you a thing or two about Mike Gunderloy. At the time of writing this book, Mike was a .NET developer working as a software consultant for “Larkware” his company which is still around. At the time Mike had many years of experience as a professional programmer. So he definitely knows and knew his stuff. In more recent times (2006) he has moved on to be Ruby on Rails developer.
He keeps a personal blog which it’s tag line describes it as being “Notes on Rails and other development”. I’ve pop by there a few times and found some very interesting links. If you pop over to his professional website you can get his email address to contact him and you can also find him on Twitter as @MikeG1.
The book tackles practical topics that are rarely emphasised in technical books, but are of extreme value and importance in real world production applications. Dry and boring ones such as logging, requirements, schedules, intellectual property. Of course you may be into that kind of thing, but I know that I don’t find them the sexiest of topics.
The book is broken down into 15 chapters which goes to varying levels of depth. At times Mike talks in very specific terms about technologies and concepts from Windows development and the .NET framework. He also provides us with an example application (a download tracker) which he tackles from time to time while moving through the book and its development life cycle.
Above I’ve listed the chapters in Mikes' book. I want to talk a bit about some of the chapters I found quite interesting while reading this book. There are a lot of valuable insights to be had throughout, but here are a few of my highlights.
For all of my professional career to date, I’ve work in large organization with defined processes around bug management and tracking. In fact much of what is discussed in this book from a process POV I’ve never given any real deep thought too because of that fact. In one sense this chapter didn’t tell me anything I didn’t know, but in another it was incredibly revealing. Of course different organization have different processes also, so the one Mike was detailed did differ from what I’ve been used to. Hence, it made me sit up and pay attention.
One of the areas I don’t have much exposure too as a programmer where I work is “Risk Management”. The way in which Mike talks about risk; how it factors into his work flow and the way in which he managed it (through statistically probabilities) resonated strongly with me. In the same way as risk management caught my attention, so too did Mikes take on “Zero Bug Goals/Mentalities”. I suppose at the time the time I was on had just committed to a zero bug goal from that point on, the quote that hit me hard was this:
Microsoft on Windows 2000 "Rather than focus on a zero-bug goal, they focused on having zero unfixed bugs that required fixing"
Finally, the main reason I really enjoyed this chapter was Mike would go into detail about his own particular independent software development set-up. For instance, when advocating for robust testing for your application, Mike describes his own test set-up (a lot of PC in his home office). I guess I just loving hearing about that kind of thing, a developer going out there and making it on their own!
The thing that absolutely rocked this chapter for me was Mikes advise for lone developers, and how they might go about testing their software without a dedicated QA team.
Honestly, I would never have thought that anyone could say so much about logging. What Mike managers here was astonishing. Now some people out there will find nothing new here, and this is a chapter where Mike goes into specifics about Microsoft Windows development tools such as the Microsoft Windows Enterprise Instrumentation Framework (EIF). But you see, there were some concepts in here that I had never encountered. Some of the frameworks that exist for .NET development sound quite incredible and of course this is an old book so I could only imagine what kind of cool technology exists now.
I’ve read a bit about logging as a concept before and Mike just hammered home some of the ideas I’ve been reading.
I don’t know how it was possible to write so many interesting things about documentation, but Mike did it. I suppose on one level it might be down to where I work, and having those kind of concerns taken care of for me by other engineers. Mike explores first the importance of documentation, both from the POV of the customer using your products and to the engineers working on with your API (if you are on a small team, or producing an API for someone to use). What interested me the most was the idea around information architecture, how do you make good documentation (for the end user), how can you avoid make something which is based on “Mystery Meat Navigation”. Who would of thought that information architecture was something that would give me kicks? I know I didn’t.
In another chapter, “Generating Code”, Mike explores the idea that you might be able to automatically generate a certain amount of your documentation as well. Which, though not a new concept/idea, is always a good to remain engineers that it’s a possibility.
One of the criticisms I’ve seen levelled at this book on-line is its heavy use of specific technologies while discussing various topics. On one level I would agree with these criticisms, it would of been nice to know I was getting myself into a Microsoft Windows/.NET take on becoming a better developer. Outside of that though I don’t think it’s completely valid. Using platform/technology specific examples exposes you to possibilities. I’m not a .NET developer, but when exposed to the types of ideas that can be found in that stack; as a result I wanted to know if the same was available for the systems I use and believe for. I believe you should always be exposing yourself to new ideas and concepts. It is true that a book might not be the best place to be exposed to those kind of ideas, but I didn’t think it took away that much from the experience.
Would I recommend “Coder To Developer”? It’s a well written book attempting to tackle very complex topics which at times get sidelined but reveals very interesting nudges of information all the same. I enjoyed the book and feel I was able take away a lot from reading it.
To purchase Coder To Developer head on over to Amazon and grab yourself a copy.
References:
]]>I drive an ‘Opel Corsa 1997’. I should say I did drive one, as I recently got an upgrade of a ‘VW Golf’. The Corsa was great, it got the job done and it was great getting the freedom a car affords you. That being said, it was a Spartan driving experience. No ABS, no power steering, a cassette player instead of CD…etc. The bare essentials and nothing but. Which is what makes driving a powerful modern car like a Golf a delightful experience. It handles beautifully, has real power in it’s engine. It’s responsive and definitely feels safer.
There was a moment recently, while driving where I was sailing up a steep incline on my way somewhere, when I didn’t quite hit the ‘bite point’ and you get that awful drop in power, you panicking to get to a lower gear and to keep moving for fear of stalling. That was the moment when it hit me. All cars have the same kind of interface to control them. How much they do for you can vary wildly. Driving a car well isn’t about the controls, don’t get me wrong, they are incredibly important. Driving a car is about the nuances of its operation, about constantly assessing how different it is to your ‘a prior’ knowledge of how a car operates.
When it comes to programming its about few things: knowing you basics and knowing them well, constantly “restating your assumptions” and seeing how they are affected by what you are doing, being engaged.
]]>When I heard of this idea at first, I was fascinated. However, on reflection I realised that I did in fact, learn in a similar way when I thought of my school days and copying work down from the black board. This probably served a similar purpose? However, “copywork” has a few distinct differences all the same.
Depending on which author or authority on the subject you were to talk to at the time you’d get a different perspective. Copywork is as much about concentration, spelling, grammar, memory as it was about study. Some authors for instance would read a paragraph/page and try to reproduce it from memory. Over and over again, until they got it right. The blog post even mentioned how Jack London employed this technique in an aid of finding his voice and improving his style after initially being rejected by publishers.
What strikes me the most about this idea/practise is it is nothing new to me. I’ve spent countless hours, playing along to music I love in the same way. I’m also aware painters and sculptors spend a lot of their time recreating the work of the greats, all in search of a better understand of them and themselves. To find their voice, style and niche.
And how/could, I now wonder, I used this technique with programming? How is programming different to any other creative discipline I’ve mentioned? Would one benefit from transcribing the full source code of a program most consider to be brilliant? What would those code bases even be? And how would you even approach it?
Well I have some answers to these questions, as I’ve been trying this technique out. I’m going to update the blog at some later date with the exact details, but suffice to say, it’s hard work.
]]>As I bring it up, that is kind of the reason I sort of walked away from it, for the moment at least. I kind of noticed that I wasn’t solving a problem, I was resolving it and probably in a not very useful way either.
I’ll get back to it someday I reckon though.
]]>Anyway, I’ve taken some time off and one of the things I’ve been looking into is JavaFX, I’ve been following an excellent guide by “Marco Jakob” over at this site on creating a simple address book application using the technology.
What I like about JavaFX, what I’ve seen of it so far… is the kind of separation it is putting between your code base and the look and feel and flow of the application. It reminds me of .NET and WPF, which I think are kind of good technologies.
]]>Using Google Code Pro, it’s clear there is a lot of dead code. From just reading the comments and translating them using Google Translate a lot of them are extremely redundant. There is a lot of pointing out the obvious, commenting for the sake of commenting and not enough about why certain decisions were made. Comments are about the why, not the what.
I haven’t drawn up or used any software to derive the design of the overall application; from what I can gleam from the code base, there is none. Just lots of singletons, massively nested code sections and God objects.
Lots of the work is done on the GUI, which isn’t that bad in the current application design, on a standard desktop it’s very quick, too quick to be an issue. Realistically I would like there to be a lot less of these kind of blocking operations.
Other issues with the code base are:
The type of plan I would propose at this point is, putting a good suite of tests in place, a job which I have started by using Code Pro to generate a fair whack of them yesterday. Because I intend on making a final token release of this software for people who may or may not still be using it I intend on just making some subtle refactors to the code base and cleaning up some ugly behavior on the front end. A more longer term plan would be the refactor the code into a more client/server architecture and perhaps move towards a more web-based approach. At the very minimum I would like to experiment with JavaFX for the frontend. Sorry mac peeps, this apps going to end up looking very different.
]]>