FAQ about ITMarketplace
What is ITMarketplace?
ITMarketplace is a community of supply and demand that aims to sustain a fun and meaningful IT marketplace.
What do you mean by fun?
Fun could be one of the following:
- minimal learning curve (see Docker 1.12 in swarm mode) aka making users awesome (by Kathy Sierra)
- easy to use (such as Turnkey Linux)
- you concentrate more with the tasks at hand (not fighting your software)
- it means you have more time with your personal life (than pretending to be working)
Are you affiliated with open source vendors?
No. ITMarketplace is a vendor-neutral community. We have high standards for usability. If we endorse a specific open source software, it is because we believe they have met our expectations of functionality that is easy to use and with minimal learning curve.
However, there are no sacred cows. Once our choice of software has become bloated or drifted away from its supposed usability, we won’t hesitate to drop it from our list.
What is your view about jQuery?
For small business apps that are basically CRUD, jQuery may get the job done. We believe in libraries, not frameworks. If you want to get fancy, you may try VueJS but we don’t use frameworks like AngularJS or Ember.
What is your view about Node.js?
Why JSON Web Token and not cookies?
Please read here.
Why JSON for Web services?
Because it is the de facto data transport for the Web, not XML.
Why MessagePack for microservices?
What is your view about microservices?
Microservices are nothing new. They are same old ideas of loose coupling. However, as distributed system software evolves to maturity, we are seeing the complexity being reduced to engines. It becomes fun to program again because we are seeing the promise of microservices as small code, not monolithic software.
How do you approach microservices?
As a community that is basically focused on Go language, we approach microservices from an event-driven perspective. There is nothing wrong with callback as long as it is not nested callback. At ITMarketplace, we program microservices using NATS and/or NSQ based on the philosophy of 12-Rule App.
Why Go language?
Usability, UNIX philosophy and its tooling. Go sets a high standard for other programming languages to follow. Rust is good too but for now, we are focusing with Go. With Go, all you need is LiteIDE and it is available for Linux, Mac and Windows.
What is your view about RPC?
RPC is a form of pull-based processing. The ubiquitous example is the Web. A Web client be it a mobile or desktop computer forwards a request to a Web server. It’s the typical client/server example.
However, we don’t use gRPC, go-kit, go-micro and the like.
You can use NATS as RPC. See NATS for microservices.
Are virtual machines still relevant?
VMs are not going the way of the dodo just as social media can’t eliminate email in this industry. VMs are very much alive in public cloud environments. However, they are seeing its decline with the proliferation of more nimble application machines (aka containers).
However, that is subjective.
The more important question is, which tasks are suitable for VMs and which tasks are suitable for containers.
It all boils down to wisdom.
What container platform are you using?
With the advent of Docker 1.12 in swarm mode, this is the technology to beat. Kubernetes, Habitat.sh and Nomad are good alternatives but not as easy to use from a developer workflow (though we are seeing usability wars brewing).
Do you believe in OOP?
How do you deal with leaky abstraction?
Leaky abstractions like ORM, configuration management tools and frameworks like go-kit and go-micro are not being used at ITMarketplace. They are like monolithic APIs whose answer to any question is yet another API. It is not a solid abstraction. That is why you have to peek behind the black box to learn how it works, which defeats the purpose of encapsulating complexity to an engine.
The trouble with frameworks is that, it is somebody else’s abstraction.
You are better off to solve it your way because you understand the problem much better than anyone else.
This is WHY we advocate “anything goes”.
Why prefer unit testing than continuous integration?
First and foremost, we are not against continuous integration (CI). In fact, we advocate Drone.io if you want one. However, CI is for software. If you are developing apps, CI may be overkill although you can build your own CI workflow with some orchestration using the command line.
Why the rage against API?
APIs are not bad per se. What is bad is monolithic API. Just as we rage against monolithic software like those in the enterprise, we should revolt against monolithic APIs.
To quote Jesper Louis Andersen,
Protocols are far better than APIs because they invite multiple competing implementations of the same thing. They debug themselves over time by virtue of non-interaction between peers. And they open up the design space, rather than closing it down. In a distributed world, we should not be slaves to API designs by large mega-corporations, but be masters of the protocols.
What’s your software stack?
- Turnkey Linux
How about Java?
No offense to all Java folks but we don’t use Java or any JVM-based language. We believe Docker is the new runtime platform and it can accommodate other interpreted languages as well.
Do you use ORM?
No. ORM is a leaky abstraction. See explanation here.
What are the bad parts in Go?
You better read Will Yager’s article. This is not to malign Go language. However, you have to use Go based on its design. You adapt to the language, not the other way around.
Having said that, I think Go is a fairly low-level programming language. That is why it is suited for writing infrastructure software.
If you are developing business apps, you better use callbacks instead of channels. Just a callback, not nested callback.
What is your development workflow?
Install Go and LiteIDE. Testing is being done on a Turnkey Linux VM using VirtualBox (no need for Vagrant). When using containers, we simply upload the single binary to Turnkey Linux VM (no Vagrant, just vbox) and build the container on top of the VM. No need for complicated build procedures. If you want to automate, be my guest but we don’t use traditional configuration management tools.
Why not use configuration management tools?
Again this is to remind everyone of the primary importance of understanding the problem first before jumping to a premature solution.
As Matt Jaynes said,
You should get your house in order before aspiring to do automation or CD.
Or from one of my own collection of aphorisms:
You cannot automate what you barely understand.
This is not to say you have to progress slowly.
As Mark Zuckerberg said,
Move fast and break things.
As a proof of concept of how I view configuration management, head over to https://github.com/ibmendoza/anchor. It is a CM proxy that lets you decide how you want the result of the script to be processed by you. Heck, you can build you own CM tool using anchor and NATS if you wish.
Why the fuss about YAML?
It is not beginner-friendly according to the experience of Hashicorp guys (see https://github.com/hashicorp/hcl). It is not intuitive so you better use TOML which is a usability win?
Why the fuss against Agile methodologies?
Because it is “anything goes”. Zed Shaw said it better.
Why the fuss against DevOps?
DevOps is one of those abstract words that is open for various interpretation. At ITMarketplace, the buck stops with one word: Docker in Swarm mode.
For more detailed rant against DevOps, read it here. You owe it to yourself to change the IT industry for the better.
What’s your favorite quote?
One from Linus Torvalds:
“Regression testing”? What’s that? If it compiles, it is good; if it boots up, it is perfect.
Who is your favorite: Edison or Tesla?
To falsifiability what is objective. To each individual what is subjective.
What else do you want to say?
It’s documented at ITJumpstart.wordpress.com. Enough said!