In my previous post on the Stateless Single-Responsibility Object (SSRO) approach to C# application composition I reviewed the concept and its shortcomings.
To recap:
Read more on Functional C# Application Composition, Part 2: Delegates…
Functional code is easier to test than code with state or side effects. However, most developers spend the majority of their time in traditional, imperative languages. There’s plenty of value in those imperative languages, but these days when I use one, I also try to bring in applicable functional concepts.
In this post I will explore how a stateful, Object-Oriented approach to composition became painful to me, and in my next post I will discuss my proposed functional solution. Read more on Functional C# Application Composition, Part 1: Shortcomings of Single-Responsibility Objects…
Any realistic application is hard to test. Often much of the complexity is unavoidable, but sometimes things are harder than they need to be. Read more on Automation Road Blocks: Altering the Behavior of an ASP.NET Server for Tests…
System tests are a crucial piece of testing any application. I’m a big believer in isolated unit tests as well, but if I had to pick just one kind of test to use, it would be system tests. There is no substitute for actually exercising the full code base from top to bottom.
That said, I don’t know if any one thing about software development has caused me more frustration than system tests. Read more on Automating Artifact Generation on Capybara(-Webkit) Failures with Autopsy…
I recently attended the Progressive F# Tutorials event in DUMBO, New York. It was a really great experience, and I think much of that is due to the way it was both a conference and more than a conference. Specifically, many of the talks featured hands-on tutorials, which provided a great opportunity to learn and digest new things.
For example, after opening remarks by Don Syme — F#’s original designer — I went to a session where he taught us about F# Compiler Services by providing a sample project with exercises to complete. He then went around from table to table helping anyone who was struggling. Quite naturally, this also encouraged us to work together with the others at our table, and we enjoyed getting to know each other and working together to solve the exercises. All in all, I found it a much more satisfying learning experience than just slides and a demo.
I also really enjoyed that afternoon, where Jack Pappas talked about writing compilers in F#, and his sample project with exercises even went so far as to include NUnit tests. That really struck a chord with this test-driven developer, to the extent that I got so excited about going from red to green I initially missed one of the exercises that didn’t include a failing test. Read more on “Progressive F# Tutorials” |> Reflections…
Four months ago I became a father. My daughter’s birth changed my life in a million ways. Most of these are good (there’s nothing in this world that compares to your child’s smile), but it has also meant less sleep and especially less spare time. I’ve learned a host of new skills that are pretty different from the ones I hone as a software developer.
That said, the two domains are not totally unfamiliar. Here are just a few ways working on a software project is like being a parent.
What babies need and what software projects need can change in the blink of an eye. Six months in, it turns out rocking your baby to sleep isn’t cutting it anymore — she needs her favorite toy and for you to sing a song to her. That’s not all that different from working on a web app that takes off, and suddenly you need to worry about things like internationalization and bandwidth and Facebook login. In no time at all, you’ve gone from milk to solid food. Read more on Six Ways Developing Software Is Like Being a Parent…
Partial application is awesome. I love it. Same goes for functions as first-class citizens. I wish these were features in every language. I’m working in Ruby right now, and every time I use map() or reduce(), I find myself wishing I had them.
class MyClass def negate(x) -1 * x end def add(x, y) x + y end end obj = MyClass.new values = [1,2,3] # this is needlessly verbose values.map do |val| obj.negate(val) end # [-1, -2, -3] # this is disgusting values.map(&obj.method(:negate)) # Ruby, why u no allow this? values.map(&obj.negate) # although dropping the & would be even better # And how about instead of this values.map do |val| obj.add(2, val) end # we could just do this? values.map(&obj.add(2)) |
To overcome these limitations (and because it sounded fun), I started looking for a gem that would help with writing code that supports partial application. Read more on Funkify and Pattern-Proc: Messing with Ruby for Fun (but probably not profit)…
As a software consultancy, we often perform additional or maintenance development on a previous project. It’s great to be able to maintain positive customer relationships and provide good value to them, but I admit I often dread returning to an old project. The main reason for my fear and trembling is trying to get the development environment up and running again. In the interim since the last time I (or someone else) touched the project, any number of things can go wrong. Just recently I encountered the following nightmare dependency change:
Read more on Testing Web Apps Developed via Vagrant Using Capybara…
I’ve spent the last year working in C# and WPF. Over a few blog posts, I have alluded to a particular pattern of structuring code, referring to it as “stateless single responsibility” objects or “stateless SRP” objects. For the purposes of this post I will call the pattern “stateless single responsibility principle” (SSRP) objects. I’d like to go into a bit more detail about what the pattern is and why I use it.
I think it will be simplest to begin with an example problem we might use my pattern to solve, then show how I would do it and explain all the parts. Read more on Functional(ish) C# & MVVM: Single-Responsibility and Code-as-Data…
I’ve been happily using the Ninject Dependency injection library on my C# project for over a year.
In order to keep my project even reasonably organized, I quickly started using Modules to group together my dependencies. For the most part in my project, my Modules correlate to the first layer of namespaces beneath the project root. Additionally, because of the way I organize my classes (adhering to the Single Responsibility Principle (SRP) and highly compose-able), many of my Modules consisted primarily of stateless SRP classes, whose only injected constructor arguments are other stateless SRP classes. These classes are essentially stateless, and should therefore have singleton implementations. In addition, to make mocking easier, most of them are the sole implementation of an interface.
Conceptually, this is all sound, but it didn’t take long until typing this got really old: Read more on Ninject Tips: Some Binding Magic & Kernel Cleanup…
