Papertrail Diary 2

The new .app domains became available this week and of course I was too slow to get papertrail.app. Too bad, but I already knew that I have to find another name at some point to prevent some trouble if I want to bring it to the App Store. I’ll try out some other ideas and see what sticks in my head. I still love the name - it would be perfect - but it’s too obvious for it to still be available.

I started development this week and I’m already stuck a bit. I want the basis to run as soon as possible, but that’s also some of the hardest parts to work on. The internal architecture should be flexible and I definitely want to implement it in a test-driven way. But that also needs some thinking first. It looks simple from the outside but when taking a closer look and if it should be flexible enough to be ready for new features in the future there are lots of different ways it could look like. So, there’s some back and forth with different ideas and I’m not quite sure I’m taking the right path at the moment. I think I need to take a step back and delete what I coded so far to get an unbiased view on the project again.

Some might ask why I want to develop a pet-project Test-driven. It’s simple: there’s no other way for me to develop an app and be confident about my code and that changes don’t break anything. I’m coding on another project at work at the moment and it’s just great to see it grow through the tests. I can make additions and changes and still know that everything works without testing all the other things manually. It’s also satisfying to see the number of tests grow and having all the green checkmarks show up in Xcode. It gives me a great deal of confidence that it’s good what I’m working on. The code I produce that way is much cleaner and easier to understand. It makes you think about how everything works in a totally different way. Another huge benefit is the time I save when I have to fix or adjust some parts that are affected by changes and additions. The time I put into the tests pays off multiple times in the long run. But that’s just my opinion. Others might not want to put in the effort to develop that way. For me it’s the only way going forward.

I’m thinking of putting out some stats every know and then to track the progress. Not sure I’ll stick with it though. Such metrics barely show the real progress, but it’s interesting to see some numbers from time to time. So here’s something for today:

I currently used the Master/Detail project Template from Xcode. It gives you something to start with, although barely anything of the original code will be left at the end. There’s some code in it though, and in order to see how many lines of code I produced I wanted to keep track of the starting point.

4 text files.
4 unique files.                              
1 file ignored.

github.com/AlDanial/cloc v 1.76  T=0.01 s (316.4 files/s, 26497.2 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Swift                            4             78             54            203
-------------------------------------------------------------------------------
SUM:                             4             78             54            203
-------------------------------------------------------------------------------

This is where everything started. Only the actual code of the main app. No libraries or tests included. Let’s see how this will look like in the future!