5 days Ago
 The Bechdel Test (Wikipedia) is a gender-bias test that “asks whether a work of fiction features at least two women who talk to each other about something other than a man. The requirement that the two women must be named is sometimes added.”↩
 For example, Redford’s character asks the idiotic and purportedly provocative question that included the hypothetical “when Pakistan starts killing women in soccer stadiums […]”, I wondered whether his hyperbolic depiction of Pakistan as an Islamist stronghold with Sharia law was due to ignorance on the part of the scriptwriter or Redford’s character’s ignorance or whether it was US propaganda injected into the film to form people’s opinions about Pakistan more negatively.↩
 There are several pretty glaring plot holes, but they don’t really ruin anything. The one that comes to mind is that, when Loki went back to the house at the end of the film, he saw crews working the frozen ground, looking for more evidence of other abductions. However, there is a car parked on top of a giant piece of plywood right next to them. It doesn’t occur to anyone to ask “I wonder what’s under here?” Instead, they dig into frozen ground and rely on Loki hearing Keller’s stupid whistle before they realize that there might be a prisoner stashed under the plywood.↩
6 days Ago
Encodo has never been about maintaining or establishing a monoculture in either operating system, programming language or IDE. Pragmatism drives our technology and environment choices.
Each project we work on has different requirements and we choose the tools and technologies that fit best. A good fit involves considering:
History: Delphi and Java
When we started out in 2005, we’d also spent years writing frameworks and highly generic software. This kind of software is not really a product per se, but more of a highly configurable programmable “engine”, in which other programmers would write their actual end-user applications.
A properly trained team can turn around products very quickly using this kind of approach. It is not without its issues, though: maintaining a framework involves a lot of work, especially producing documentation, examples and providing support. While this is very interesting work, it can be hard to make lucrative, so we decided to move away from this business and focus on creating individual products.
Still, we stuck to the programming environment and platform that we knew best (and that our customers were requesting): we developed software mostly in Delphi for projects that we already had. For new products, we chose Java.
Why did we choose Java as our “next” language? Simply because Java satisfied a lot of the requirements outlined above. We were moving into web development and found Delphi’s offerings lacking, both in the IDE as well as the library support. So we moved on to using Eclipse with Jetty. We evaluated several common Java development libraries and settled on Hibernate for our ORM and Tapestry for our web framework (necessitating HiveMind as our IOC).
A few years later, we were faced with the stark reality that developing web applications on Java (at the time) was fraught with issues, the worst of which was extremely slow development-turnaround times. We found ourselves incapable of properly estimating how long it would take to develop a project. We accept that this may have been our fault, of course, but the reality was that (1 )we were having trouble making money programming Java and (2) we weren’t having any fun anymore.
We’d landed a big project that would be deployed on both the web and Windows desktops, with an emphasis on the Windows desktop clients. At this point, we needed to reëvaluate: such a large project required a development language, runtime and IDE strong on the Windows Desktop. It also, in our view, necessitated a return to highly generic programming, which we’d moved away from for a while.
Our evaluation at the time included Groovy/Grails/Gtk, Python/Django/Gtk, Java/Swing/SWT/Web framekworks, etc. We made the decision based on various factors (tools, platform suitability, etc.) and moved to .NET/C# for developing our metadata framework Quino, upon which we would build the array of applications required for this big project.
We’re still developing a lot of software in C# and .NET but also have a project that’s built entirely in Python. We’re not at all opposed to a suggestion by a customer that we add services to their Java framework on another project, because that’s what’s best there.
We’ve had some projects that run on a Linux/Mono stack on dedicated hardware. For that project, we made a build-server infrastructure in Linux that created the embedded OS with our software in it.
Most of our infrastructure runs on Linux with a few Windows VMs where needed to host or test software. We use PostgreSql wherever we can and MS-SQL when the customer requires it.
We’ve been doing a lot of web projects lately, which means the usual client-side mix of technology (JS/CSS/HTML). We use jQuery, but prefer Knockout for data-binding. We’ve evaluated the big libraries—Angular, Backbone, Ember—and found them to be too all-encompassing for our needs.
We’ve evaluated both Dart and TypeScript to see if those are useful yet. We’ve since moved to TypeScript for all of our projects but are still keeping an eye on Dart.
We use LESS instead of pure CSS. We’ve used SCSS as well, but prefer LESS. We’re using Bootstrap in some projects but find it to be too restrictive, especially where we can use Flexbox for layout on modern browsers.
And, with the web comes development, support and testing for iOS and other mobile devices, which to some degree necessitates a move from pure .NET/C# and toward a mix.
The description above is meant to illustrate flexibility, not chaos. We are quite structured and, again, pragmatic in our approach.
Given the choice, we tend to work in .NET because we have the most experience and supporting frameworks and software for it. We use .NET/C# because it’s the best choice for many of the projects we have, but we are most definitely not a pure Microsoft development shop.
I hope that gives you a better idea of Encodo’s attitude toward software development.
 If it’s not obvious, we employ the good kind of pragmatism, where we choose the best tool for the job and the situation, not the bad kind, founded in laziness and unwillingness to think about complex problems. Just so we’re clear.↩
 Remo had spent most of his career working with Borland’s offerings, whereas I had started our with Borland’s Object Pascal before moving on to the first version of Delphi, then Microsoft C++ and MFC for many years. After that came the original version of ASP.NET with the “old” VB/VBScript and, finally, back to Delphi at Opus Software.↩
 We were actually developing on Windows using Delphi and then deploying on Linux, doing final debugging with Borland’s Linux IDE, Kylix. The software to be deployed on Linux was headless, which made it much easier to write cross-platform code.↩
 For better or worse; we inherited a Windows GUI in Python, which is not very practical, but I digress↩
 Which is almost always, unfortunately.↩
1 week Ago
John Oliver’s new show on HBO is what some of us have always wanted the Daily Show to be. Oliver doesn’t self-censor, he doesn’t do pandering interviews and he does really, really in-depth segments. He did one recently on inequality.
Watch the whole segment below.
2 weeks Ago
I’ve seen a bunch of articles addressing this topic of late, so I’ve decided to weigh in.
The reason we frown on returning
It seems to me that the proponents of “no nulls” are generally those who have a functional language at their disposal and the antagonists do not. In functional languages, we almost always return sequences instead of lists or arrays.
In C# and other functional languages, we want to be able to do this:
This seems like exactly the kind of code we’d like to avoid writing, if possible. It’s also the kind of code that calling clients are unlikely to write, which will lead to crashes with
The post, Is it Really Better to ‘Return an Empty List Instead of null’? / Part 1 by Christian Neumanns (Code Project) serves as a good example of an article that seems to be providing information but is just trying to distract people into accepting it as a source of genuine information. He introduces his topic with the following vagueness.
The statement “we can see that not all people agree” is a tautology. I would split the people into groups of those whose opinions we should care about and everyone else. The statement “There are many different, sometimes truly opposite opinions” is also tautological, given the nature of the matter under discussion—namely, a question that can only be answered as “yes” or “no”. Such questions generally result in two camps with diametrically opposed opinions.
As the extremely long-winded pair of articles writes: sometimes you can’t be sure of what an external API will return. That’s correct. You have to protect against those with ugly, defensive code. But don’t use that as an excuse to produce even more methods that may return
The second article Is it Really Better to ‘Return an Empty List Instead of null’? − Part 2 by Christian Neumanns (Code Project) includes many more examples.
I just don’t know what to say about people that write things like “Bugs that cause NullPointerExceptions are usually easy to debug because the cause and effect are short-distanced in space (i.e. location in source code) and time.” While this is kind of true, it’s also even more true that you can’t tell the difference between such an exception being caused by a savvy programmer who’s using it to his advantage and a non-savvy programmer whose code is buggy as hell.
He has a ton of examples that try to distinguish between a method that returns an empty sequence being different from a method that cannot properly answer a question. This is a concern and a very real distinction to make, but the answer is not to return
The method providing the sequence should not be making decisions about whether an empty sequence is acceptable for the caller. For sequences that cannot logically be empty, the method should throw an exception instead of returning null to indicate “something went wrong”.
A caller may impart semantic meaning to an empty result and also throw an exception (as in his example with a cycling team that has no members). If the display of such a sequence on a web page is incorrect, then that is the fault of the caller, not of the provider of the sequence.
That there exists calling code that makes assumptions about return values that are incorrect is no reason to start returning values that will make calling code crash with a
All of his examples are similar: he tries to make the pure-data call to retrieve a sequence of elements simultaneously validate some business logic. That’s not a good idea. If this is really necessary, then the validity check should go in another method.
The example he cites for getting the amount from a list of PriceComponents is exactly why most aggregation functions in .NET throw an exception when the input sequence is empty. But that’s a much better way of handling it—with a precise exception—than by returning
But the upshot for me is: I am not going to write code that, when I call it, forces me to litter other code with null-checks. That’s just ridiculous.
In the previous two articles, we managed to reduce the number of queries executed when opening the calendar of Encodo’s time-tracking product Punchclock from one very slow query per person to a single very fast query.
Because we’re talking about latency in these articles, we’d also like to clear away a few other queries that aren’t related to time entries but are still wasting time.
Lazy-loading unneeded values
In particular, the queries that “Load values” for person objects look quite suspicious. These queries don’t take a lot of time to execute but they will definitely degrade performance in high-latency networks.
As we did before, we can click on one of these queries to show the query that’s being loaded. In the screenshot below, we see that the person’s picture is being loaded for each person in the drop-down list.
We’re not showing pictures in the drop-down list, though, so this is an extravagant waste of time. On a LAN, we hardly notice how wasteful we are with queries; on a WAN, the product will feel…sluggish.
What is a load-group?
In order to understand the cause of these queries, you must first know that Quino allows a developer to put metadata properties into different load-groups. A load-group has the following behavior: If the value for a property in a load-group is requested on an object, the values for all of the properties in the load-group are retrieved with a single query and set on that object.
The default load-group of an object’s metadata determine the values that are initially retrieved and applied to objects materialized by the ORM.
The metadata for a person puts the “picture” property of a person into a separate load-group so that the value is not loaded by default when people objects are loaded from the data driver. This is a good balance because business logic will avoid downloading a lot of unwanted picture data by default.
Business logic that needs the pictures can either explicitly include the picture in the query or let the value be lazy-loaded by the ORM when it is accessed. The proper solution depends on the situation.
Lazy-loaded property values
As before, we can check the stack trace of the query to figure out which application component is triggering the call. In this case, the culprit is the binding list that we are using to attach the list of people to the drop-down control.
The binding list binds the values for all of the properties in a metaclass (e.g. “person”), triggering a lazy load when it accesses the “picture” property. To avoid the lazy-load, we can create a wrapper of the default metadata for a person and remove/hide the property so that the binding list will no longer access it.
This is quite easy, as shown in the code below.
With this simple fix, the binding list no longer knows about the picture property, doesn’t retrieve values for that property and therefore no longer triggers any queries to lazily load the pictures from the database for each person object.
The screenshot of the statistics window below shows up that we were successful. We have two main queries: one for the list of people to show in the dropdown control and one for the time entries to show in the calendar.
For completeness, here’s the code that Punchclock is using in the current version of Quino (1.11).
Future, improved version
Once we fix the but in the
This concludes our investigation into performance issues with Quino and Punchclock.
You may have noticed that these calls to “load values” are technically lazy-loaded but don’t seem to be marked as such in the screenshots. This was a bug in the statistics viewer that I discovered and addressed while writing this article.↩
This is a rather old API and hasn’t been touched with the “fluent” wand that we’ve applied in other parts of the Quino API. A nicer way of writing it would be to create an extension methods called
But that will have to wait for a future version of Quino.↩