jehugaleahsa

Encoding math

I have been spending the last month reading Euler's Elements of Algebra. It's an interesting way of teaching and learning algebra because it's broken out into small paragraphs that introduce algebraic rules one at a time and tries to relate them to each other in some logical sequence. It's a little odd some times, though, because right after learning about logarithms, you go back to subtraction.

One strange thing I learned about myself in college is that I am much better at math involving variables than I am numbers. I've always been slow adding 5 + 6 or taking 8 * 9. Most people by the time they're out of 3rd grade can't even help but recite the answers. Not me - I still have to think about it everytime. I find it strange, then, that I am much more comfortable reducing expressions like 3x^2 + 9x + 12. In fact I get a kick out of it! Euler's book is geared much more toward people who like my kind of math.

One

jehugaleahsa

Angular 2 - Supporting Nested Model-Driven Forms

Introduction - It worked in AngularJS

If you build real business applications, then you know most of your development effort goes into forms. AngularJS struck me right away as an amazing improvement over the previous generation of HTML libraries, simply because model binding was really well done. Integrating binding with validation made it a first-class web framework.

Business applications of any moderate complexity often have reusable user controls and AngularJS directives were great for that purpose. AngularJS had this amazing feature, whereby placing an ng-form inside of another ng-form the state of the child form was automatically reflected in the parent! You could build up directives with their own validation completely independent of what page they belonged to. Simply by dropping them on your page, all of your validation was auto-wired up. Brilliant!

It doesn't work in Angular2

It is a little surprising, then, that Angular2 did not follow in

jehugaleahsa

calculate :: [String] -> Maybe Double
calculate [] = Nothing
calculate a = calculateHelper a []
    where
        calculateHelper [] [a] = Just a
        calculateHelper ("+":items) (x:y:rest) = calculateHelper items ((y+x):rest)
        calculateHelper ("-":items) (x:y:rest) = calculateHelper items ((y-x):rest)
        calculateHelper ("*":items) (x:y:rest) = calculateHelper items ((y*x):rest)
        calculateHelper ("/":items) (x:y:rest) = calculateHelper items ((y/x):rest)
        calculateHelper (a:items) rest = case (readMaybe a :: Maybe Double) of

jehugaleahsa

A lot of cool things have happened in the last year or so that really get me excited. We got to see .NET core reach all new platforms; TypeScript has quickly become my favorite language; we saw Angular 2+, React, Webpack and other awesome tools bring the web into the next generation. Five years ago, I wasn't a big fan of web development -- it seemed way too chaotic for my tastes. It took some time, but now I love that chaos! It doesn't bother me that my node_modules folder contains over 22K files.

I would be extremely happy if I spent 100% of my time programming in TypeScript by 2020. I have some wild dreams about what would enable that possibility. One possibility is I switch to using Node.js for all of my backend coding, foresaking more than 10 years of C# experience and the awesome power ASP.NET Core promises. I take the .NET framework for granted -- I know -- I worked in Python for 4 months and was constantly annoyed how disconnected all the libraries felt. The JavaScript community sees a lot more chur

jehugaleahsa

# let rows: 10
# let lines = from row in 0..rows
#             let spaceCount = rows - row
#             let spaces = " " * spaceCount
#             let stars = "*" * (2 * row + 1)
#             let line = spaces + stars + spaces
#             select line
# lines.join("\r\n")

jehugaleahsa

The Inane Insistence on Patterns Pertaining to Persistance

An annoying pattern

I have been noticing an annoying pattern lately. Whenever I hear about a new project starting, more often than not, I see someone on the team jump into "DB architect" mode. For those individuals, literally every last ounce of energy goes into designing the database. Worse, they want sole ownership and literally forego all other development activities until they are satisfied.

It has been a long time since I've seen a requirements document that was thorough enough or accurate enough that I could devise a perfect database on day one of the project. I have two guesses why some developers are drawn to early database design: 1) it gives them a sense of control over the project, thinking it establishes them in some essential role; or 2) they have been burned too many times in the past with bad database designs.

My experience is that quality software projects grow organically. When you start a new project in Visual Studio, you're n

jehugaleahsa

A Transition to Statelessness

Introduction

In 2012, I took a psychedelic journey into the world of functional programming. I started learning some ML-based languages, including F#, OCAML and Haskell. I also discovered Scala, which is now one of my all-time favorite languages.

I think too many people stop learning functional programming before they get into the really interesting parts. Filter/map/reduce is just the tip of the iceberg. Even if that is all you end up learning, you should at a minimum take to heart Command Query Separation. But the real meat of functional programming comes in the form of closures, partial application, currying, high-order functions and immutability. Check out this C#:

Func<int, int> getAdder(int value)
{
 return i =&gt; i + value;

jehugaleahsa

The Early Years...

I was one of those eager college grads that went and read the GOF's Design Patterns. Being pretty fresh to development in a professional setting, I used design patterns everywhere, even where they didn't belong. I've also read a ton of books on OOP and software architecture and they had a huge influence on my past projects.

Jaded

Now that I've been at it for about 10 years, I've seen a sharp decline in the number of design patterns I use. In terms of UML and OOP, I barely even think about them anymore. Some of it's just that I'm so familiar with them that I don't really notice when I'm using them. The rest is because I just don't find myself reaching for them as often as before. Recently, I've noticed a sharp correlation between the use of abstract classes and increased code complexity. So, I usually rely on composition and helper classes for my shared functionality. I use interfaces mostly to support dependency injection and unit testing.

Every now and then, I whip out the Deco

jehugaleahsa

[LayoutRenderer("event-id-json-data")]
public class EventIdLayoutRenderer : LayoutRenderer
{
	private const string _eventIdKey = "EventId";

	private static JsonSerializerSettings _jsonSettings = new JsonSerializerSettings
	{
		NullValueHandling = NullValueHandling.Ignore
	};

jehugaleahsa

    import scala.language.reflectiveCalls

    def using[TResource <: { def close(): Unit }, TResult](resource: => TResource)(action: TResource => TResult): TResult = {
        val instance = resource
        try {
            action(instance)
        } finally {
            instance.close()
        }
    }