Wednesday, July 22, 2015

Example SFlow

Previously I mentioned a project, execon, which I'm planning to rename SFlow, however, one of the missing pieces for the casual reader is what's it all about?

BEFORE

func DeleteMerchInfoHandlerOld(w http.ResponseWriter, r *http.Request) (int, error) {
        if r.Method != "DELETE" {
                return http.StatusMethodNotAllowed, errInvalidMethod
        }
        payloadValue := r.FormValue("payload")
        if payloadValue == "" {
                return http.StatusBadRequest, errExpectedEmpty
        }

        request := mdata.RemoteRequest{}
        if err := json.Unmarshal([]byte(payloadValue), &request); err != nil {
                return http.StatusBadRequest, err
        }

        merchInfo := mdata.MerchInfo{}
        if err := transcode.Transform(&merchInfo, request); err != nil {
                return http.StatusBadRequest, err
        }

        if found := merchinfo.Dirty(merchInfo); found == false {
                return http.StatusBadRequest, errMerchNotFound
        }

        return http.StatusOK, nil
}

AFTER

type DeleteMerchInfo struct {
        Init                 execon.ExeConTask `params:"FIRST"`
        MustDeleteMethod     execon.ExeConTask
        PayloadNotEmpty      execon.ExeConTask
        ParsePayload         execon.ExeConTask
        CastPayloadMerchInfo execon.ExeConTask
        SetMerchInfoDirty    execon.ExeConTask `switch:"{\"HttpError\":\"Finish\"}"`
        Finish               execon.ExeConTask
        Error                execon.ExeConTask
        HttpError            execon.ExeConTask
        FuncLib
}

I don't want to spoon feed the reader with all of the gory details but there were a bunch of things that I learned in the process of converting this workflow.

  1. The AFTER is so much easier to read
  2. The AFTER is so much easier to extend
  3. The AFTER takes advantage of shared code library
  4. The AFTER can actually be assembled, composed or generated from textural fragments or gists
  5. The BEFORE did not have enough documentation
  6. The BEFORE did not consider some other options
  7. The BEFORE required the user to interpret the summary description
As a side effect there were a number of testcases that I missed. There were a few test cases that were broken and needed fixing. And in one case I had missed a use-case that needed to be tested. And while I was working in this particular "switch" (above) I found that I missed a case in the framework implementation. (for another day; but no one is perfect).

No comments:

Post a Comment

dead pixels

I have never had a dead pixel so when I read: Small numbers (1-3) of stuck or dead pixels are a characteristic of LCD screens. These are n...