When I started out as a wee programmer back in the 1980s, “Hungarian Notation” was all the rage. Invented by Charles Simonyi (a Hungarian guy!), it espoused a naming convention for variables that included the intent (or kind, or type) for that variable. Unfortunately, the semantic meaning of type is overloaded, and many developers assumed it meant “data type.” So, you had variables that were clearly string variables called strFirstName or clearly integer variables called intCount. In a type-safe compiled language, this is redundant, but many Microsoft devs, myself included, blindly followed the pattern because we learned it, and it made sense on the surface.
I am constantly asked by desktop developers how to make the transition to web development. Web applications are almost as powerful and as fast as desktop applications these days. There are no installation hassles as web applications reside in just one place: on your server. The user simply navigates to their application's starting point on their browser and can immediately start working. In this blog post, I provide you with guidance on how experienced developers can get started with web programming. I am not going to go in-depth into each technology and tool. Instead, I will introduce you to terms, technologies, and tools needed for web development, and provide you with links on where you can learn more about each.
Sometimes, you may need to upload files to your server via an Angular application. There are a few different methods you may use. Today, I am going to present a method that works well for small files up to about two megabytes in size. In this blog, you build two projects: a .NET Core Web API project and an Angular project. You build these two projects from scratch using the Angular CLI, .NET Core, and Visual Studio Code editor.
Mock objects are an important driver of test driven development (TDD). They give developers the ability to craft unit tests involving complex objects without risking the possible complications inherent in instantiating those objects. They can be used to test code’s behavior when things go wrong, when infrequent things happen, or when a complex system of objects needs to be in a specific state. They are good for testing methods that return non-deterministic results (like the current time), and standing in for objects you plan to build, but haven’t built yet. In short, they’re useful, but xCode does not support them out of the box.
Apple’s xCode ships with OCUnit which is “a faithful implementation of xUnit patterns for Objective-C”[Vollmer]. Though useful for testing (it provides the various combinations of assertions covering nulls, exceptions, true, false, and equality), it lacks the capability to produce mock objects. That’s where OCMock comes in. OCMock is a library that works with Objective-c and provides methods that allow you to employ mock objects throughout your own applications. In this post, I’ll be walking through the setup of OCMock in Apple’s xCode environment and running through a few basic use cases for the OCMock library.
Jonatan Heyman, co-creator of Locust, hunted my blog post down and provided some helpful info in the comments (see below). I've updated this post with the relevant info (just look for bold text as you scroll down). Hooray Jonatan! I promise not to swarm locust.io with my locust scripts!
Locust is, if you believe the hype, the HOLY GRAIL of obscure Python-based distributed load testing tools with real-time web-based statistics:
I’ve tried a few different times to get Locust up and running on Windows, and every time something has gone wrong enough for me to be demotivated and quit. ‘Cause, y’know, I’m a quitter.
My goal is to help YOU get Locust setup on your Windows machine in the “recommended” way, so you can bring down your server by flooding it with thousands of requests too. There is something awe-some about having the power to bring down a server remotely just by typing “100,000” in the “How many users?” input box… Please note that Locust is really designed to run on Unix/Linux, so if you are able to run your Locust load tests from there, please do.
In this post I'm going to describe how to automatically generate diagrams from source code. I've found that diagrams provide the quickest path to understanding how a piece of software works. Diagrams also provide a great means to discuss software at a high level. They've proven invaluable in the software development and software consulting work I've done.
Often diagrams are created by hand. Unfortunately hand-crafted diagrams are prone to manual mistakes and falling out-of-sync as the source code changes. Many IDE's can automatically generate diagrams from source code on the fly, but sometimes your IDE doesn't provide the diagrams or options you want. Being able to generate your own diagrams will give you the ability to create exactly what you need when you need it.