// You are building an educational website and want to create a simple
// calculator for students to use. The calculator will only allow
// addition and subtraction of positive integers.
// We also want to allow parentheses in our input. Given an expression
// string using the "+", "-", "(", and ")" operators like "5+(16-2)",
// write a function to parse the string and evaluate the result.
// Sample input:
// expression1 = "5+16-((9-6)-(4-2))"
// expression2 = "22+(2-4)"
// Sample output:
// evaluate(expression1) => 20
// evaluate(expression2) => 20
Recently, I did a live session where I was challenged to implement some code in a short period of time. I got flustered, and I diverged from my usually strict principles of code etiquette and wrote some messy code that never ended up working by the end of the session. I had an elegant solution in mind, but I was worried about time and ended up with this mess.
I have been running a hybrid Linux/Windows box for some time now, using Xen. Xen is a bare-metal hypervisor with many powerful features, including the ability to map physical hardware (say, a graphics card) to guest VMs. I have struggled with getting USB to work seamlessly, however. My hardware prevents me from mapping a physical USB device to the guest, so I needed a different solution.
Xen allows emulated USB controllers to be mapped to the guest, and this works well. One important feature is missing, however. It is not possible to automatically connect a device to the guest when it is plugged in.
A lot of research and some diving into the code brought me to a solution, however. Utilizing the udev interface in linux and the low-level hypervisor interfaces, I can hot-plug devices at run-time. This post describes how I got there.
Last week, I attended a networking event, as a “dry run” for an upcoming push toward getting out there with our new consulting arm, ModPii. I observed some things that I found interesting, and would probably be of use to others out there.
(I had this sitting in draft form for years now, and I just dug it up. Most of it is pretty obsolete, with .net core and all, but I’ll just leave this here.)
In a previous post, I discussed a method for using abstract classes in ASP.NETMVC 4.0. With it, I was able to clean up and hide the details of implementation from much of my code. I assumed that it would be relatively simple to do the equivalent in Web API, but I found that the task to be quite different.
The equivalent functionality requires use of asynchronous programming, code generation, and some complex processing for handling things like IEnumerable. I also found some race conditions that needed to be addressed.
As a part of the API for our product, we have the need to allow the UI to send us a parcel of data, and we need to process it differently based solely on a single parameter in the data. We have decided to create an abstract model class to handle this, but MVC’s DefaultModelBinder doesn’t work out of the box on abstract classes (or interfaces). There are many discussions out there on this, and the accepted way to solve this problem is to create a new ModelBinder class that has more knowledge of the internals of your application than the default does. I thought about this some, and I decided to try out a few tweaks to the process.
I came upon a requirement at work to support accepting multiple ids in the Url of a “REST” request. I have no idea if this is actually considered RESTful or not, but the task was to formulate the URL like so:
The intention was to be able to retrieve multiple instances of FooResource with one request.
So, I came up with the following MVC ActionFilter to make my life a little bit easier:
So I am having a bit of a problem here. Working on a simple library for a client to help them maintain their Active Directory entries programatically. Started with my tests. (I took this opportunity to spike Machine.Specifications, which I am finding that I quite like, but that’s for a different post.) Then researched into the APIs available from Microsoft. At first, I was quite excited about the System.DirectoryServices.AccountManagement namespace added in the 3.5 framework, until I tried to inject its classes into my own.
Now I’m running myself in circles, trying to figure out how to test my code without creating (or worse, deleting) accounts on my development box.
The development team has recently relinquished our individual offices in favor of a team room where we are all working together. At first, I was skeptical that I would be able to keep a high level of productivity with the distractions that a team room, by its very nature, creates. I couldn’t have been more wrong. We quickly meshed as a team and have become noticeably more productive. (You can see the slope change on our burndown; it is dramatic!)
One of the side-effects of working in a big room with the rest of the team is that I’ve started to notice the different development and personality styles of the different members. I’ve come up with several different general categories. Some people cross these boundaries, depending on the situation.
Last night of the iteration, we are trying to cut a good build. This morning’s scrum featured a flustered QA engineer who was having trouble completing her tests due to “corrupted data”. Developers look at each other and think, “rebuild the VM”, but it really turned out to be faulty (and inconsistent) assumptions, on all of our parts.
The root cause of all our problems tonight, though, dates back to the removal of a database constraint that supported an assumption that was not removed, about three iterations ago. (A questionable design decision, IMHO.) This iteration, we tried to add a new constraint that enforced our (now refined) assumption in a different way. We failed. The assumption had been broken in several places, including our test data. Now, as we are trying to go gold, we have found that we need to revert the constraints and deal with the messy data, just so that our test suite will continue to work.
Now, in theory, in the field, nobody should be breaking things. But we are still allowing them to, so somebody will, and it will look bad for us. We are stuck between a rock and a hard place now. Thirty minutes spent coming up with a better design three iterations ago would have had us at home with our wives and a beer three or four hours ago.
Here at work, we have been running into a lot of issues synchronizing the default configurations provided by the developers with those that have been provided by the team responsible for packaging releases. The system as it is right now is, how shall we say, clunky, at best, requiring the developers to go back and reconfigure new features multiple times throughout an iteration, often every evening before the nightly build.
This simply will not stand.