Tego microservice framework

Spent several hours on my Ied Holiday to continue Tego , it’s heavily inspired by go kit. Now I’m convinced that go kit has good balance of flexibility even though it’s far from echo on the easy to use side. However I can say that this structure allows code with 100% test coverage easy to achieve.

On Tego I was literally copied go kit endpoint’s code and adding set for ergonomic. Other than that there are several simplifying here and there. Lot’s of time spent on creating the sample apps to dogfood the tego itself, you can definitely create a complete by following the autocomplete example.

Advertisements

Basic Software Process Nature

About software process :

The special nature of SPs can be defined as follows:

a) They are complex.

b) They are not typical production processes, since they are exception driven, are strongly affected by highly unpredictable circumstances, and each process has peculiarities that distinguishes it from all others.

c) They are not ‘pure’ engineering processes either, since we do not know the appropriate abstractions, (there is no experimental science behind them), they depend too much on too many people, their design and production are not clearly differentiated, and their budgets, schedules and quality cannot be programmed reliably enough.

d) They are not (entirely) creative processes because some parts can be described in detail while some procedures are previously enforced.

e) They are finding-based and depend on communication, coordination and cooperation within predefined frameworks. Their delivery generates new requirements, the cost of changing software is not usually recognised, and their success depends on user involvement and the coordination of many different roles (sales, technical development, customer, etc.).

Ruiz-González,Francisco; Canfora, Gerardo; “Software Process: Characteristics, Technology and Environments” (PDF), European Journal for the Informatics Professional, 5 (5): 6–10

Intercepting Http Response writer in Go

Sometimes we have to use http handler written by external library which we don’t want to change. It’s all fine until we need to know what the handler does, like what is the status code written to the response header.

In Go net/http it’s not possible to read the response directly for many good reason. Luckily ResponseWriter is interface!

Here is example of the interceptor, to get status code.

type HTTPResponseInterceptor struct {
	http.ResponseWriter
	StatusCode int
}

//NewHTTPResponseInterceptor create new httpInterceptor
func NewHTTPResponseInterceptor(w http.ResponseWriter) *HTTPResponseInterceptor {
	return &HTTPResponseInterceptor{w, http.StatusOK}
}

//WriteHeader override response WriteHeader
func (i *HTTPResponseInterceptor) WriteHeader(code int) {
	i.StatusCode = code
	i.ResponseWriter.WriteHeader(code)
}

The usage is pretty straight forward, wrap the writer with the one from the interceptor. Below example is how I used in my toy project, to get status code then update echo context status code.

func (i *Index) GetIndexHandler(context echo.Context) (err error) {
	i.bleveGetIndex.IndexNameLookup = func(*http.Request) string {
		return context.Param(i.indexNameLookupKey)
	}
	w := util.NewHTTPResponseInterceptor(context.Response().Writer)
	i.bleveGetIndex.ServeHTTP(w, context.Request())
	context.Response().Status = w.StatusCode

	return
}

I need 2 hours to come up with this solution, but it’s worth the time.
Quick googling give me this blog post which does exactly the same http://ndersson.me/post/capturing_status_code_in_net_http/

Talking about Qt vs HTML5 whitepaper

It was in the middle of midnight when I stumbled upon a white-paper comparing Qt QML app development with web app development. I like the idea to compare these two wonderful technology, however more I read the white-paper more I dislike it. I think it’s just another misleading marketing stun. Let’s dive down a bit on this white-paper titled Qt QML vs HTML5 – A Practical Comparison.

So in this whitepaper an Austrian company tasked a developer to build an Embedded Application using QT and HTML5, the developer had 160 Hours to build the QT version then another 160 Hours for the HTML5 version. The developer was experienced in HTML5 and C++ but had little experience on building QT/QML apps.

From this point please read the whitepaper before continuing this post, for complete context.

The result

I think there is one main misconception which leads to inappropriate comparison in this whitepaper.

The definition of Embedded Application; I would say embedded application would come in packaged and controlled target machine, like for webapp we can pick whichever browser our app work best. And for QT apps would mean which operating system and hardware platform the apps is targeted, so we can limit the build number to release. On both software stack or in embedded application generally, limiting target environment means less testing and less extra variable to take into account.

Continue reading