Since these are blogs, there are no guarantees as to the accuracy or readability of the information contained therein. The entries are also a mix of German and English (Don't worry...one language per entry!)
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:
For over a year, I’ve been writing articles about various parts of Quino. A customer asked if I could collect those links into a coherent table of contents, to make it easier to use as a reference.
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!
The summary below describes major new features, items of note and breaking changes. The full list of issues is also available for those with access to the Encodo issue tracker.
This release is a “bridge” release that has the entire new Metadata API as well as the older version, which is marked as obsolete. It is intended that projects upgrade to this version only temporarily in order to more easily migrate to the 4.0 Metadata API. At that point, projects should immediately upgrade to Quino 4.0, from which all obsolete methods have been removed. Once 4.0 is available, there will be no more bug-fix releases for this release.
MetadataBuilderand base classes and improve dependency-resolution
From a customer, we got the request to apply a visual style guide (VSG) to a Bootstrap-based application. Since we do have a lot of experience with applying style guides on web applications and styling in general, we accepted the job and started to evaluate the details.
The most recent stable version of Bootstrap is 3.3.6. However, when you go to the Bootstrap website, there is an announcement that Bootstrap 4 “is coming”. The current state of Bootstrap 4 is alpha and the last blog post is from December 2015 which is almost half a year ago. It also is not clear, when version 4 finally will be available and stable and so we had to use the old Bootstrap 3 for this project.
But even here, there is some obscurity going on: Bootstrap was initially developed with LESS but for some reason they decided to switch to SASS. Even if we prefer to use LESS at Encodo, we decided to use SASS for this project to be able to upgrade to Bootstrap 4 more easily when... [More]
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]
The article .NET Core, a call to action by Mark Rendle exhorts everyone to “go go go”.
I say, “pump the brakes.”
Mark says, “The next wave of work must be undertaken by the wider .NET community, both inside and outside Microsoft.”
No. The next wave of work must be undertaken by the team building the product. This product is not even Beta yet. They have called the last two releases RC, but they aren’t: the API is still changing quite dramatically. For example, the article Announcing .NET Core RC2 and .NET Core SDK Preview 1 lists all sorts of changes and the diff of APIs between RC1 and RC2 (GitHub) is gigantic—the original article states that “[w]e added over a 1000 new APIs in .NET Core RC2”.
That is a huge API-surface change between release candidates. That’s why I think these designations are largely incorrect. Maybe they just mean, “hey, if y’all can actually work with this puny footprint, then we’ll call it a final release. If not, we’ll just add a bunch more stuff until... [More]