Saturday, July 27, 2013

Idiomatic Web Server for the Enterprise and others

Web Servers come in a rainbow of colors and flavors. Think of Apache, Nginx, Lighttpd, Zeus and IIS are among the leaders with application, REST, and custom servers filling in the gaps. However, with the power of GoLang's goroutines and standard library one could make the argument that if the remaining functionality existed (or at least the required mods) then a hybrid GoLang web server would be a real possibility; the benefits are clear.

(1) fewer applications - fewer dependencies
(2) obvious transaction flow - predictable

Thursday, July 25, 2013

internet radio costs

How is it that all of the internet radio players from google, spotify, rdio, and pandora (to some extent) all have the same price point? (not that there needs to be a loss leader but the pricing seems too regulated... and unless that regulation comes from government; wouldn't that be a monopoly?

Tuesday, July 23, 2013

Linux containers

Interesting to compare to vm solutions. Very good for non-shared SaaS. 

Sunday, July 21, 2013

My requirements for the ideal DSL

I do not want to create a primer or answer the question as to what a DSL is (domain specific language) but I recognize that the line between a successful programming language and a ubiquitous uber programming language is somewhere between the range of problems that a language can solve. For example languages like C, C++, and assembler are excellent for low level programming but one can get tangled at high level. Languages like Go, C#, erlang and Java (CLR, Mono, JVM, Beam/EVM) are better at medium level challenges and most dynamic languages like perl, Ruby, JavasScript and Python are better at high level problems.

Going back to Dave Thomas's (pragprog) AU Ruby Conf keynote. Paraphrasing: The power of any DSL is that it's ideally suited for the complexity of the challenge it solves making the programmer productive.

A side note: I have purposefully left out languages like CoffeeScript, Elixir and Clojure because they are more akin to translations than they are standalone; and they simply do not solve any more problems than they inherit from their environments etc...

Up until this point in the argument I have been examining these languages from the level at which the programming interacts or develops application. From this perspective languages are broken into 3 components. (1) syntax; (2) APIs; (3) execution.

syntax; The differences in most languages is most dramatic in the syntax. It's the place where most novice language designers think the definition of a DSL is. Almost all syntax looks the same. That's probably because todays language tools like YACC and LEX, BNF etc help the language designer get to market quickly. So with the exception of concepts like Object-Oriented, lambda, and closures (and some other concepts) I think it's safe to say that ALL modern programming languages are more similar than they are different.

APIs; unless the language provides direct access to the system hardware like registers and memory; everything, if exposed, is going to be provided in the APIs. The difference between the high and low level language APIs is the amount of protection the API provides for the user and the overall efficiency and implementation. For example 'C' lets the operating system detect the memory errors while Java and C# perform that task (whether they defer to the OS and intercept or preempt is not important)

execution; There are many variations to this model. From a binary with statically linked in libraries; or dynamic linked libraries; virtual machines like the CLR, Mono, JVM and EVM and more(DartVM, LuaJit); or complete interpretive runtimes like perl, perl6(I think), Ruby, Python, JavaScript. Execution is the biggest barrier to the DSL and the DSL environment because it's easy to translate a DSL into a language that already has an execution path and it's hard to get to a clean path. (how many GCC preprocessors do we really need).

One interesting idea is some sort of mutation. The demo I watched was the conversion of the UnReal engine from 'C' to JavaScript(and the demo rocks!). They accomplished the task in two ways. (a) they compiled the C code with the LLVM and then converted the code in the LLVM to JavaScript. (b) the optimized JavaScript was then running on asm.js which is a stripped down and performant JavaScript environment.(further optimized for FireFox). Unfortunately this is in the opposite direction.

My requirements for the ideal DSL:

  1. easily digested idiomatic "one solution" syntax
  2. rich APIs partitioned vertically by task and horizontally by complexity
  3. execution as a binary or with an embedded interpreter or JIT
For me; the ideal DSL is one DSL that allow me to write a device driver, implement a dynamic website backend, or generate a PDF report from a CSV.

Saturday, July 20, 2013

The real pair programming

Pair programming and modern development shops is implemented where one programmer has hands and eyes on the keyboard and the second programmer is leering as the first programmer codes. This increase your costs by 2x Without realizing any immediate benefit.

Rather than having the second program or simply leering over the first programmers Code. The second programmer should be writing test cases to test the first programmers code. In this way both programmers are still collaborating to complete the task.

What is the actual return on investment when implementing agilemethodologies

Implementing agile methodologies is like replacing all of your incandescent lightbulbs with LED lightbulbs. At least when upgrading your lightbulbs you know what the return on investment is. Depending on when you purchased lightbulbs in the initial cost ROI is approximately 2 to 3 years according to current estimates.

But when it comes to Agile methodologies how much of it is incremental and how much of it is generational improvement. When you consider the cost of training, consultants, resources, software upgrades and new purchases. Just how cost-effective is this methodology or is it just disruptive? When addressing pair programming it tends to be endorsed by individuals who have never or will never pair. Especially leadership. Is the 2x cost per line of code really better or a misinterpretation of the task?

UPDATE: Another great article on Agile rebuttal.



Something I learned for my daughter today

It's not always about the nap but the preparation for the nap. 

Wednesday, July 17, 2013

Sunday, July 14, 2013

Is Lenexa kernel development considered agile

How is it that a handful of developers who are considered benevolent dictators still manage to incorporate such large changesets into the Linux kernel and yet outspoken leaders like Linus Torvalds are highly opinionated? What does this say about everyday development in large and medium size companies whom rely on standard agile methodologies, scrum methodologies and Kanban methodologies?

Documentation generator

As an homage to Knuth' literate programming it would be great to generate documentation from code by using proper coding style and technique. 

Literate code is the real Commented code

We have all come to assume that commented code means the inclusion of comments, however, as we evolve it seems that we prefer code that is easy to read. Or literate code. Thank you DK but we don't need a language to accomplish this just better ideas. 

Saturday, July 13, 2013

Docker and docker-registry; first and second reaction

My first reaction to docker was that I was going to do a lot more with a lot less.  I was interested in using docker containers to deploy jails and such for various private web servers; many serving static content. That mission was delayed as I realized that the docker registry is public access. And while the content is meant to be consumed it is the property of their owners. Not a good idea.

So I thought I would deploy my own docker registry. One look at the config file and I realized that I need to have an S3 account. Which is probably why they do the public thing and why dotcloud is so expensive. (Amazon does not give great discounts as it's meant for the enduser and not the reseller)

I'll have to look at libvirt directly now. It can access lxc containers directly and that in itself might be a winner.

Thursday, July 11, 2013

C100K and C250K on nodejs

I am somewhat skeptical that they actually managed to get C100K and C250K on an Amazon server. However, I'm very skeptical that they got any real work done on that machine. Partly because of the overhead per connection (up to 4K on some operating systems) but that doing real work has severe  implications for every component in the system. From network IO to disk IO.

Making the connections is easy. Doing real work is hard.

Tuesday, July 9, 2013

Golang simple mock benchmark

A very simple echo server (http) written using the basic net/http package was able to process 5890TPS with go1.1.1 on a 2012 MacBook Air. 

Monday, July 8, 2013

You `Mako Server` Me Crazy

Mako Server's benchmarks are impressive and I'm very curious how they managed to double the page rate of Apache. It's too easy to be a critic...

  • dynamic files, depending on complexity, are easier to produce
  • mako server is a micro server and therefore does not have all the features or protections that Apache does
I think the biggest difference is the licensing. Mako's prices seem reasonable but they are not free as in beer or anything else. Frankly there are so many other servers out there that are FREE that mako needs to fall off my radar.

Sunday, July 7, 2013

Transcoding into JavaScript can/is wasteful

No matter what you still need to be a JavaScript expert transcoding is just trading one set of idioms for another. Time would be better spent on a stricter lint. 

Wednesday, July 3, 2013

Feature Flags are Essential

when building a non-trivial continuous delivery or deployment system you will absolutely require feature flags for every single change that goes into the system.  This will allow devops or even traditional operations to enable new features or patches as well as providing the ability to disable the patch or feature... and all systems can be synchronized at once.

It's a trivial feature but so powerful.

erlang on xen - again

This is a nice writeup. It's easier to read than from the source. There are a number of problems with this project:

1) closed source until they make some money
2) limited to 512 files in the filesystem
3) the compiler is custom and is not compatible with beam files
3a) build/package requires using their service (your code is not private)
4) is still very limited in functionality

as apposed to docker:
5) docker can launch a hello world app in 20ms on a basic Rackspace server
6) provides jailed systems no different that VM
7) no overhead from the VM
8) access to real filesystems
9) will run anything you can run normally
10) fully instrumented
11) uses the LXC container
12) free
13) actively developed by the hoards.
14) and will run erlang as a beam... also elixir... as-is

erlang on xen is interesting but novel.

Organizing iPhone apps

I decided to sort my apps on my iPhone by their purpose whether it's input or output. And then within the tab I will sort by function. 

Tuesday, July 2, 2013

Monday, July 1, 2013

Zero downtime for go

The goagain library is fantastic. It permits to smooth transition between versions of a go application with zero downtime. There are a few more things to say about it. Many of the signals are not implemented limiting its overall functionality. And there is a design flaw or two. However it is functional and does perform the main task of zero downtime.

another bad day for open source

One of the hallmarks of a good open source project is just how complicated it is to install, configure and maintain. Happily gitlab and the ...