Clashing Protocol Functions Cannot Be Disambiguated
I’m going to classify this as Swift issue but only because it’s a new language. The same problem exists in Objective-C. I’ve already reported it to Apple and it’s on Open Radar as well.
Description Consider a class implementing two protocols with clashing function declarations (name + all parameter types). Currently there is no mechanism to disambiguate which function is being a) implemented and b) invoked. The compiler collapses the implementation of the clashing function to be invoked for both protocols even though these may have very different semantics (as function name will depend on the protocol context)
Frugal Cloud
Why do we optimize? I’m used to optimizing the speed and memory consumption to improve the user experience, to allow new features that would otherwise be prohibitively expensive, to be able to do more in less, to avoid forcing customers to upgrade their hardware unnecessarily and so on. But this rarely if ever has direct effect to the cost of the product to you as developer.
Enter cloud-based products and this all changes and suddenly when you optimize your code you often do it to both save you money and improve user’s experience.
Continuous Development
In the past year there have been two major productivity boons in my workflow:
git which I now use exclusively and which I could only use privately before (and was thus using it in a half-assed way) using modules (npm, RubyGems and to some minor extension CocoaPods) (well, these two plus going back to the terminal after so many years in GUI environments)
I needed time to get used to both of these but with the difference that git obviously is tightly integrated into development workflow whereas using modules also has significant impact on deployment.
Clean Heroku Npm Cache
This originally appeared on coderwall.
Today I ran into an issue with Heroku and the way its official buildpack for Node caches node_modules. Namely, I was forced to fork a couple of modules so I updated package.json to point to GitHub repositories (see this tip).
Unfortunately, Heroku stubbornly refused to modules from the updated path and actually npm wasn’t behaving much better on my local machine either but there at least I could manually delete the node_modules and re-install everything.
Fork and Patch Npm Moduels Hosted on Github
This originally appeared on coderwall.
I have read How to fork & patch npm modules and followed the instructions but I couldn’t make it work for me. Looking at npm log I figured that the problem was with zip files being downloaded and not tarballs. So here’s the trick on how to include your GitHub repository correctly in npm:
Go to fork’s page Go to commits On the right side of the commit you want to use click “Browse code” On the browse code page right-click on “Download ZIP” button (or whatever it is that you are seeing) and copy the URL.
Host More Than One Node Server on a Single Heroku Dyno
During development I often host an express server for frontend and one or more backends in a single node process. They all listen on different ports and communicate over HTTP, keeping the modules completely separated and the interfaces clean.
But that doesn’t work on Heroku which gives each dyno just one port. This is fine in production where all those servers will have their own dynos but during development I prefer this single-process configuration as:
Bitten by Package Versions
My first Node.js service was a simple personal logging service that I put up at the beginning of the year. It was a personal project, hacked in a couple of weeks of very sporadic work and I didn’t pay much attention to its deployment. So today I tried to move its database backend to Cloudant (moving away from IrisCouch which for me has been extremely unreliable) but in the meantime (the last deployment was 10 months ago) the connection between the local repository and Heroku app got lost so I instantiated it as a different app (luckily as you’ll see later).
No Silver Bullet
TL;DR: 25+ years after it was written “No Silver Bullet” by Fred Brooks still delivers an extremely relevant framework for thinking about software development but don’t take my word for it but read it
I would like to say that I have read No Silver Bullet by Fred Brooks some 20 years ago. Or at least 10. But I can’t. I read it for the first time last week followed immediately by “‘No Silver Bullet’ Refired”.
Elastic Software Development
TL;DR: An effective software development process for the kind of software that I build needs to be high frequency and elastic to customer demands.
I have just read another great post From Agile to Elastic by @ralfwen is the continuation of his previous post about which spurred me to yesterday. I’m going to go in depth on this one as it matches very closely with my current understanding of how software development I’m involved with should be done.
Product Development as Drilling
I can’t seem to stop making up these analogies of what is product development. The last time it was a sandwich and now it’s drilling:
Drilling is a cutting process that uses a drill bit to cut or enlarge a hole of circular cross-section in solid materials. The drill bit is a rotary cutting tool, often multipoint. The bit is pressed against the workpiece and rotated at rates from hundreds to thousands of revolutions per minute.