I encountered some curious behavior while writing a service-locator interface (_protocol_) in Swift. I’ve reproduced the issue in a stripped-down playground and am almost certain I’ve found a bug in the Swift 3.0.1 compiler included in XCode 8.2.1.
We’ll start off with a very basic example, shown below.
The example above shows a very simple function, generic in its single parameter with a required argument label
a:. As expected, the compiler determines the generic type
T to be
I’m not a big fan of argument labels for such simple functions, so I like to use the
_ to free the caller from writing the label, as shown below.
As you can see, the result of calling the function is unchanged.
Let’s try calling the function with some other combinations of parameters and see what happens.
If you’re coming from another programming language, it might be quite surprising that the Swift compiler happily compiles every single one... [More]
Check out two new talks on our web site:
Check out two new talks on our web site:
Microsoft recently published a long blog article Introducing .NET Standard. The author Immo Landwerth appeared on a weekly videocast called The week in .NET to discuss and elaborate. I distilled all of this information into a presentation for Encodo’s programmers and published it to our web site, TechTalk: .NET Standard 2.0. I hope it helps!
Encodo has long been a two-space indent shop. Section 4.1 of the Encodo C# Handbook writes that “[a]n indent is two spaces; it is never a tab.”, even though “[t]he official C# standard […] is four spaces.” and that, should you have a problem with that, you should “deal with it.”
Although we use our own standards by default, we use a customer’s standards if they’ve defined their own. A large part of our coding is now done with four spaces. Some of us have gotten so accustomed to this that four spaces started looking better than two. That, combined with recent publicity for the topic, led me to ask the developers at Encodo what they thought.
We discussed ABD in a recent article ABD: Refactoring and refining an API. To cite from that article,
“[…] the most important part of code is to think about how you’re writing it and what you’re building. You shouldn’t write a single line without thinking of the myriad ways in which it must fit into existing code and the established patterns and practices.”
With that in mind, I saw another teaching opportunity this week and wrote up my experience designing an improvement to an existing API.
Before we write any code, we should know what we’re doing.
IMetaAspects) in Quino to add domain-specific metadata (e.g. the
IVisibleAspectcontrols element visibility)
FindOrAddAspect(). This method does what it advertises: If... [More]
We’ve been doing more internal training lately and one topic that we’ve started to tackle is design for architecture/APIs. Even if you’re not officially a software architect—designing and building entire systems from scratch—every developer designs code, on some level.
There are broad guidelines about how to format and style code, about how many lines to put in a method, about how many parameters to use, and so on. We strive for Clean Code™.
But the most important part of code is to think about how you’re writing it and what you’re building. You shouldn’t write a single line without thinking of the myriad ways in which it must fit into existing code and the established patterns and practices.
We’ve written about this before, in the two-part series called “Questions to consider when designing APIs” (Part I and Part II). Those two articles comprise a long list of aspects of a design to consider.
First make a good design, then compromise to fit project... [More]
On Wednesday, Encodo had its first networking event of the year. Our very own Sebastian Greulach presented Code Review Best Practices. A bunch of our friends and colleagues from the area showed up for a lively discussion that, together with the presentation, lasted over 90 minutes.
We heard from people working with remote teams—off- and near-shored—as well as people working locally in both small and large teams and for small to large companies. We discussed various review styles, from formal to informal to nonexistent as well as the differences in managing and reviewing code for projects versus products. Naturally, we also covered tool support and where automation makes sense and where face-to-face human interaction is still better.
The discussion continued over a nice meal prepared on our outdoor grill. We even had a lot more vegetables this time! Thanks to lovely weather, we were able to spend some time outside and Pascal demonstrated his L337 drone-flying skills—but even... [More]
This first-ever Voxxed Zürich was hosted at the cinema in the SihlCity shopping center in Zürich on March 3rd. All presentations were in English. The conference was relatively small—333 participants—and largely vendor-free. The overal technical level of the presentations and participants was quite high. I had a really nice time and enjoyed a lot of the presentations.
There was a nice common thread running through all of the presentations, starting with the Keynote. There’s a focus on performance and reliability through immutabiliy, sequences, events, actors, delayed execution (lambdas, which are relatively new to Java), instances in the cloud, etc. It sounds very BUZZWORDY, but instead it came as a very technically polished conference that reminded me of how many good developers there are trying to do the right thing. Looking forward to next year; hopefully Encodo can submit a presentation.
At the beginning of the year, we worked on an interesting project that dipped into IOT (Internet of Things). The project was to create use cases for Crealogix’s banking APIs in the real world. Concretely, we wanted to show how a customer could use these APIs in their own workflows. The use cases were to provide proof of the promise of flexibility and integrability offered by well-designed APIs.
The first use case is for the treasurer of a local football club. The treasurer wants to be notified whenever an annual club fee is transferred from a member. The club currently uses a Google Spreadsheet to track everything, but it’s updated manually. It would be really nice if the banking API could connected—via some scripting “glue”—to update the spreadsheet directly, without user intervention. The treasurer would just see the most current numbers whenever he opened the spreadsheet.
The spreadsheet is... [More]
At Encodo, we’ve got a relatively long history with Git. We’ve been using it exclusively for our internal source control since 2010.
When we started with Git at Encodo, we were quite cautious. We didn’t change what had already worked for us with Perforce. That is: all developers checked in to a central repository on a mainline or release branch. We usually worked with the mainline and never used personal or feature branches.
Realizing the limitation of this system, we next adopted an early incarnation GitFlow, complete with command-line support for it. A little while later, we switched to our own streamlined version of GitFlow without a
dev branch, which we published in an earlier version of the Encodo Git Handbook.
We’re just now testing the waters of Pull Requests instead of direct commits to
master and feature branches. Before we can make this move, though, we need to raise the comfort level that all of our developers have toward creating branches and manipulating... [More]