Web API FromUrl and FromBody

I've been using ASP.NET Web API for new service my lone .NET customer. They needed to build a most html/js application into the company intranet and they are only interested in Microsoft Technologies so I figured this would give me something similar to RESTful resources in Rails.

While the WebAPI certainly seems modeled after that, and it's a noble effort, I've been struggling to get routes working the way I want running into issues with nested resources and using parameters in the url. The preferred solution seems to be to use IQueryable and OData,  I don't use an ORM that implements IQueryable, and I wasn't willing to switch. So I have stumbled onto the pattern of using FromUrl to at least pass parameters in a more complex than the standard way.

An Evernote backed Journal using Vim/Emacs

I journal quite a bit and my holy grail has been using my favorite text editor (Vim or Vim bindings) with Evernote to store the everything in a smart searchable format. Today I stumbled onto a neat little tool that makes this all happen called Geeknote http://www.geeknote.me/.  It's written in Python and works fine on my Mac.

Installing Geeknote

In the directory of your choosing run the following script.  This will checkout the latest copy from source and allow you to login:

#!/bin/sh

# Download the repository.

git clone git://github.com/VitaliyRodnenko/geeknote.git

 

cd geeknote

 

# Launch Geeknote and go through login procedure.

python geeknote.py login

#change vim to whatever you want it to be

python geeknote.py settings --editor vim

 

Then add the following script and execute it from whatever directory you want to install Geeknote into

 

#!/bin/sh

 

#change checkout_dir to match where you've checked out the latest

checkout_dir=~/Documents/geeknote

#change notebook to whatever notebook you use as your journal

notebook=Journal

title=$1

if [ -z "$1" ]

then

title=$(date +%Y-%m-%d)

fi

echo creating a note named $title in the $notebook notebook

 

python $checkout_dir/geeknote.py create --title $title --notebook $notebook --content "test"

python $checkout_dir/geeknote.py edit --note $title --notebook $notebook --content "WRITE"

Writing Journal Entries

My script is named journal so for me I just type either of the following:

journal  #creates a note in journal with todays date as the title

or

journal custom_title  #no spaces allowed and will use the title specified

 

Summary

With a few simple scripts and in moments you two can be writing notes in the command prompt. I highly recommend you extend these scripts to your needs or just use the Geeknote command prompt as you see fit.  

 

Ruth’s Story

Ruth Ann Svihla came into this world screaming and angry on October 30 2011 at 6:57 am. She was and has always been a beautiful, intelligent child that brought us a great deal of joy, but she was born with many challenges to overcome.

Cleft

The first such challenge we faced was a pretty severe cleft lip and pallet. Although this turned out to the be the most minimal of her problems, it was significant at the time. She was unable to eat on her own that first day, and we had to feed her through a nose tube. Attempts to teach her how to eat were met with frustration, both from my daughter and from us as well. I went to bed that night distraught and worried at challenges of being a new father of “special needs” child. Would my wife and I be able to cope?

The next day brought more of the same, frustrated parents and angry frustrated baby. But somewhere along the way I realized that she was frustrated not with attempting to eat, nearly as much as being helped to eat. So we stopped trying to help her and she began to eat on her own instantly. We were told most cleft lip and pallet babies take 2 weeks to learn to eat as well as Ruth did that second day. Only two days old and already adaptable and fiercely independent!

A “Normal” Life

After that we settled into being mostly normal parents, my wife made weekly trips to Houston from San Antonio for her plastic surgery consults and we looked forward to the day when she would just be a “normal” kid. However, around Christmas time she became extra colicky and struggled to hold down any food, but otherwise was largely consolable. Eventually she was down to 1/4 of what she’d been able eat before and we ended up in the hospital for a week, just to try to get her some nutrition. She did well once we started getting her fed and we were ready to go home. About an hour before leaving, the doctor pulled us aside in a very concerned tone. Within the hour, we were in an ambulance on our way to Texas Children’s Hospital in Houston and so began our next chapter.

Pompe Disease

We went through so many hills and valleys with our subsequent trip to Houston, which would become our home, that it would take a book to tell it all. Let me summarize and tell you all that I have watched my daughter lose the ability to move entire limbs, to smile, to otherwise become inert for long periods of time, but I’ve also had the opportunity to watch her go through a lifetime’s worth of conquered challenges.

Pompe disease can be quite deadly and horrible to go through. The key metrics for survivability are catching it quickly (which we did), and having a type of the disease that responds to treatment (which Ruth had). The journey to finding out those two realities unfortunately took a month and a half and the damage in the meantime was quite severe. Pompe disease is exceedingly rare (1 in 40k births depending on population) and is rarely caught when it occurs. Most cases are believed to be misdiagnosed as SIDS as the infantile form of Pompe disease typically has a 6-8 month life span. Pompe patients are unable to process glycogen fully and so it stores in their muscles. Once the levels become toxic the muscle tissue becomes damaged, sometimes permanently. Despite this it can be managed often quite well, and we’d incorrectly believed at the time of her diagnosis we could return her to a “normal” life with some small challenges.

Ruth to her credit treated life as “normal”. Despite having a heart far weaker and larger than many kids on the transplant list and having a muscular dystrophy she was able to become a constant ball of motion and troublemaking whereas many kids on the transplant list are suffering.

Home

After 2 1/2 months in TCH thanks to some amazing doctors, nurses, and therapists (OT/PT and RT) we were able to go to our new home in Houston and manage her disease from there, which was within a mile of TCH so we could make her multiple per week appointments. Initially everyone was pleased with Ruth’s progress and we were filled with hope. However, after 4 months her heart remained stubbornly weak and it had actually slightly grown over the preceding months. Most kids with Pompe disease that can handle it’s primary treatment Myozyme get fully healthy functional hearts in time, their other physical attributes often never fully recover. In Ruth’s case she was able to physically move as if the Myozyme was working exceptionally well, but her heart was telling us it was not working at all.

Routine checkups can be so very non-routine

On sept 18 we checked back into the hospital after routine checkup told us her measurements for heart failure had suddenly gotten very bad.  Within the day we were told she was going to have to be intubated and at her level of heart failure it was extremely risky and likely lethal  Within 5 hours one change led to my daughter sitting up on my lap and giggling as if nothing wrong had ever happened. By 3 am that night she’d woken up half the infant pod on the CVICU floor with her squeals of delight. I realize looking back now this was the moment that Ruth proved she was just content to find what joy she could at any time. She’d had at least 2 near death experience before her first birthday, and I think she knew at some level she could feel terrible one minute and great the next, so why not just enjoy the good ones.

I wish I could tell you it was an amazing recovery after that. We tried many times to get her onto “normal” support and we failed many times to do so. Her patience with hospital care basically became zilch, however, otherwise she continued to be a very happy baby. She learned a great deal, started to sit up on her own support for up to a minute at a time, and in general was a complete joy in our life. She became very sneaky. She would spend hours trying to pull bandages off, or pull out NG tubes, and do “fake” coughs for somehow more attention. She did all of this in between the constant attention and support she received from her mother, her aunt and I, not to mention the whole hospital of people trying to help us.

Christmas

Nevertheless her heart continued to be stubborn. We tried to get the board to consider a heart transplant, but as there were many complicating medical factors I chose not to go into that could lead to the heart being destroyed in a matter of months, they were obviously unwilling to take a heart away from another kid waiting transplant that would benefit. By Christmas time the side effects of heart failure led to her lungs filling up with fluid and she became oxygen dependent. We slowly watched her fade away by inches and we were convinced that we’d lost her, despite our constant efforts and the level of care she was receiving. A preliminary genetic test came back indicating she may have a chromosomal defect related to dilated cardio myopathies. This could explain how her heart was so much weaker than is normally seen in Pompe patients, it could explain how the Myozyme was not remodeling her heart. However, this along with several other factors made her case completely unique in the truest sense (the only child on record with her genetic variant of Pompe), and so it made the path much murkier for us and for her team of doctors. It also probably meant that not only would we never be able to give her a “normal” life, and we would be in for the fight of our life to keep her alive. She could have not one by two commonly fatal conditions that have expected lifespans less than she was already alive.

Despite all of the bad news and despair her parents were feeling, Ruthie decided it was time to get better. So much so that we reduced support until we were able to get home January 18th, four months to the day after checking into the hospital this last time.

Joy and Heartache

My daughter was probably happier than all of us to be home. She was surrounded by those she loved the most and was no longer being poked and prodded by strangers. We began to believe again that she may yet surprise us and recover completely. Then one morning she became very clingy. I had to hold her that entire weekend as she seemed unable to be away from me for any length of time. After having gone through what we had I was completely content with the task of holding my daughter close, until Sunday afternoon when she became very uncomfortable. I wrote in my journal that day that I was suddenly fearful she did not have nearly as long as we’d hoped and I was afraid that this may be it. We talked to the on call medical staff, her recent labs had been a bit elevated but otherwise in range for her, they were concerned but knew we didn’t want to go back into the hospital as everyone knew we may never get back out. So we decided to make adjustments in her care to compensate (lay off some diuretics and add some pain meds) and stay home until her appointment the next morning.

Unfortunately, at that appointment her labs came back horrifyingly bad. Her kidneys were in the process of completely shutting down. We tried one last ditch attempt to save her and checked her into the hospital and tried IV therapy. You see if you have an extremely bad heart and your kidneys shut down you’re in a very bad place. Most of the interventions you’d do for one problem are blocked by the other problem. Over the next 16 hours my daughter degraded quickly. We got her quickly into hospice care and at 9am on January 30 2013 while bathed in sunlight and surrounded by family my daughter finally rested a rest that was more complete than her mother and I could ever give her.

A Lesson Of Resilience

It’s easy to see nothing but heartache and tragedy in Ruth’s story, and my humble writing skills and lack of eloquence do her an injustice. Despite this I hope you were able to see that no matter what happened to my daughter, she was happy every moment she could be. She got better every chance she got.

Through all of her tragedy and setbacks my daughter played video games meant for 7 year olds on her iPad, got to see her first birthday, learned how to smile not once but two times, had favorite movies, danced to Miles Davis and Louis Armstrong and screamed for joy an untold amount of times. I’ve never loved anything more on this earth, and I’ve never been so proud of anyone ever as my daughter. She had a mountain sized heart physically and in spirit, and she never ever gave up.

At this horrible time it’s easy to want to stop trying to try at all, but she was unrelenting in trying no matter the difficulty. It’s easy to be sad all the time, but she was happy every chance she got. It’s so incredibly easy to not want to live anymore, but that would do the ultimate disservice to her repeated attempts to live.

Rail 3.1 CI setup with Jenkins, Test Unit & SimpleCov on OS X Lion.

I recently had to setup a build server for some rails work I'm doing. Still wanting to support my other projects I setup Jenkins. I ran into several issues.

Running Jenkins as a hidden user

First I noticed that jenkins was running as the "daemon" user, this obviously wasn't going to work for github and rvm needs. So I did some googling and had some guides to get Jenkins running as a specific user. I did the following (sourced from http://colonelpanic.net/2011/06/jenkins-on-mac-os-x-git-w-ssh-public-key/ ). Note: That's really $PASSWORD up above. This gives you a prompt to enter that password. Next you'll need to stop the Jenkins service and edit the plist and start the service back up.
You're plist file should end up like this.

RVM issues

Now my next issue was despite what I'd read elsewhere I was unable to get Jenkins to use the default ruby provided by RVM. So I just pasted the commands that I would run anyway in the "Execute Shell" build step.

Getting Jenkins to see tests

I've been using Test:Unit/Minitest lately just to keep more consistent with my day to day work. However I haven't found a way to get my tests to show when using the "Execute Shell" task. I found a little gem called ci_reporter that exports to the standard junit format, unfortunately it doesn't work with minitest yet. That's ok I haven't done anything that Test:Unit doesn't support so far so I added the the following to my Gemfile (note the part about unit-test 2.0):
Running "rake ci:setup:testunit test" should give you a bunch of xml files in tests/reports. Now we need to tell Jenkins where to find those reports so add a post build action to pick them up as junit reports.

Rcov reports

This was pretty easy.

1. Install Jenkins plugin for RCov (it's in the plugin list in the admin section).
2. add simplecov and semiplecov-rcov to your Gemfile.
3. configure Jenkins rcov plugin to look in coverage/rcov
4. add the following 4 lines to the TOP of your tests/test_helper.rb file:

In closing

This took a fair amount of time, but the end result was quite satisfying. I now have CI with tests, tests coverage, RVM to target different versions of Ruby and bundler to make sure my Gem environment is sane.

The difficult definition of professional software development

Here are some of the contradictory phrases (and a few paraphrases) I've overheard used to define what is "good" and "bad" code.

• Code should always be well commented
• Maintainable code has unit tests and well named methods therefore needs little if any comments
• Class explosion is to be avoided at all costs
• Many small simple well named classes are the key to well organized code
• Unit tests really don't test anything useful
• Dependency injection leads to an unusable mess
• Dependency Injection is a very useful tool for making your code extensible and easily reused"
• Inheritance leads to solid code reuse
• Inheritance is the strongest coupling of your code you can have
• Functional programming simplifies and minimizes the complexity of your code
• Functional programing just makes my eyes bleed!
• Static global references are 'just programming' and something you have to learn how to manage to make simple easy to understand code
• Static global spiderwebs are crippling to maintenance and program lifetime

  The part that is most difficult about that list for me is while I agree with half of it strongly and respect the people who said those things, the other half that list I do not agree with, has all come from people I respect and who overall do some pretty impressive things. They've certainly created things by all measures more impressive than anything I've ever produced

  This leads me to question how much do software principles matter when taking them out of the context of yourself but viewing it in a bigger picture? Thinking about it, 95% of the software that I actually like probably wasn't using any TDD at any point in time and certainly violates a number of things that I would consider required for "professional software". I keep reinforcing this fact every time I checkout the source of a major software project I've used for years and gasp in horror at the spaghetti code I find.

  Worse still the different schools of thought are not compatible in the slightest, and one side views the other side as wholly unprofessional (granted for different reasons) to the point that I've realized I myself was perceived as the one being "amateur" by those with a different definition of what makes good and bad software. I of course unfortunately often thought the same of them, regardless of how I felt about them personally.

  Anyway, this is all food for thought and I have not yet come to any conclusion what it all means. I know I've tried coding under other schools of thought and while through practice I was able to deliver well enough, I'm far slower and more error prone with no TDD, big mega classes, and avoiding dependency injection.

Java IoC containers and classpath scanning (or what I’ve been looking for from .NET for months)

Frustrated with the typical way I saw IoC used in Java where every example I found involved thousands of lines of XML
and/or Java code to configure Java beans or components.  This is very different than IoC typically used in .NET where most IoC containers allow
you to "autowire" in their terminology up every class in an assembly with a couple of lines of code.  Having been coding in that fashion
for several years in .NET I was dismayed when none of my fellow Java coders that I worked with or knew personally had any concept
of the equivalent functionality, and instead informed me the IDE would be my help in maintaining these massive XML files.

Not content with their answers I burrowed into Spring, Guice and PicoContainer docs and found "classpath scanning" which is roughly
equivalent to "autowire" in .NET. Below is an example of this in Spring 3:

MyStuff.java (my main class note his has 2 dependencies which you can view on my github repo)

package org.foo;



import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Service;



@Service //one way of marking this as a component to register

public class MyStuff {

    private final DependencyWithNoInterface first;

    private final DependencyInterface second;



    @Autowired //tells spring which constructor to use for it's dependencies

    public MyStuff(DependencyWithNoInterface first, DependencyInterface second) {



        this.first = first;

        this.second = second;

    }



    public void run(){

        System.out.println("foo me");

        first.foo();

        second.superFoo();

    }

}

appContext.xml (seems you still need some XML)

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

       xmlns:context="http://www.springframework.org/schema/context"

       xsi:schemaLocation="http://www.springframework.org/schema/beans

           http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

           http://www.springframework.org/schema/context

           http://www.springframework.org/schema/context/spring-context-3.0.xsd">

     <context:component-scan base-package="org.foo"/>

</beans>

Application.java (the initialization)

package org.foo;



import org.springframework.context.ApplicationContext;

import org.springframework.context.support.ClassPathXmlApplicationContext;



public class Application {

    public static void main(String args[]){

        ApplicationContext ctx =   new ClassPathXmlApplicationContext("appContext.xml"); //the IoC container

        MyStuff stff = ctx.getBean(MyStuff.class); //my fully injected class

        stff.run();

    }

}

 

Now I’m sure for the .NET developers familiar with StructureMap, Windsor, Autofac, etc this is completely unimpressive. I’m also sure there are Java developers that are somewhat unimpressed with this but for reasons that involve holding onto giant configuration artifacts. Manual IoC component registration falls where hand writing SQL for trivial data access does for me, extra repetitive work that has been solved years ago. I worked in factories a decade ago, and therefore now have a low tolerance for similar activity as a professional.

Edit:

It appears you can forgo XML as well in your main class use a different Application context and add the refresh and scan lines

package org.foo;



import org.springframework.context.annotation.AnnotationConfigApplicationContext;



public class Application {

    public static void main(String args[]){

        AnnotationConfigApplicationContext ctx =   new AnnotationConfigApplicationContext(); 

        ctx.scan("org.foo"); //scans the org.foo package

        ctx.refresh(); //needed to load them for some reason

        MyStuff stff = ctx.getBean(MyStuff.class);

        stff.run();

    }

}

Anti-Pattern: Too much of your application is about interacting with external resources

Firstly, what am I talking about? Applications that meet some of the following descriptions:

1. Stored procedures with a fair amount of conditional logic or complicated business rules buried in a sub-query (some would argue sprocs at all).
2. Web pages with lots of conditional output again encoding business rules in snippets of view logic. if else checks that display the latest price for something if before and certain date or a default price.
3. The majority of ‘unit tests’ require a database, or web and application server to be up and running.
4. The majority of code files make reference to language default I/O or database libraries.
5. Hours are spent trying to determine if differences in version of infrastructure are the cause of certain bugs.
6. Changing database schema results in hours of refactoring, as hundreds of querys and sprocs are hunted through to see if this index or that index is being properly hit.

Why is this an anti-pattern? First before I bore you with endless reasoning behind SOLID principles, proper OO etc if you’re reading this and you’re of a bent that disagrees with me so far entirely..none of that will mean anything to you, and none of it will mean anything to your customers so let me put this in the most practical terms I can.
It is not testable in the slightest in any practical sense. You will be counter with well that with that sort of application and making everything a front to back test that you KNOW when things are working, yes but you RARELY if EVER know in a quick sense why things are not working. If i can reliably eliminate any chance that my actual code or business logic is the cause of a problem, if all of my fancy business rules are in something that can be run thousands of times a second, then I can throw all sorts of corner cases at my code base and not increase my verification time. If the majority of my application is business logic and plain old code then I can save my slow manual testing to the areas that are so bullet proof and only have a slice of my application doing front to back testing to yes, make sure things really work.
Note: Cross posted from Polyglots R Us.

Permalink