I am following the evolution of the Vert.x project since its inception and I was expecting to see some books coming about the subject sooner or later. First of all, some explanation on what's Vert.x:
"Vert.x is a lightweight, high performance application platform for the JVM that's designed for modern mobile, web, and enterprise applications."The product is 100% open source, licensed under the business friendly Apache Software License 2.0 and well documented. The project's founder and main maintainer is Tim Fox, of HornetQ fame. »
The book is titled Apache Maven Starter and it's part of the Instant collection by Packt Publishing. Instant books are concise and focused technical guides, usually no more than 50 or 60 pages, providing the maximum amount of information in the quickest and most effective way.
Get to grips with a new technology, understand what it is and what it can do for you, and then get to work with the most important features and tasks.The book follows a starter approach for using Maven to create and build a new Java application or Web project from scratch.
I accepted the invite to write this book because, despite the huge amount of information already available on this subject, in form of other books and online material, when I started learning Maven I was searching for more concise information. The book actually doesn't aim to be a complete reference, but a place to start from and a collection of pointers to additional information. So, it is the book I wished I could read years ago.
Maven ultimately allows for the automation of the build lifecycle and independence from any IDE. You must always be able to build and test any Java project from the command line, using your favorite editor for coding. It is important to control exactly what libraries get distributed with Java projects and to have a standard project template and build process.
Instant Apache Maven Starter will concentrate the most useful information into one single, very compact source.
What you will learn from this book
- Download, install, and configure Apache Maven with the minimum fuss
- Make your own Java project templates and reuse them
- Deploy to Tomcat or run an embedded Tomcat with Maven
- Perform unit and integration testing with Maven and JUnit
- Manage dependencies and project coordinates, adopting best practices
- Create and manage multi-modules projects
- Use Maven from your favorite IDE: Netbeans, Eclipse, or IDEA
While reading an article on ZDNet titled "Open source: Its true cost and where it's going awry by Monty Widenius" I think I have realized why most people, even those tightly involved in the open-source ecosystem, are often misunderstanding its business model. In a sentence:
The open source model is about creating collaborations, not building products.Advocating open source software since the early 90s, from my point of view an open-source business model related to products can be misleading.
"The problem is — I saw this very clearly with MariaDB — I created a company where I took the original people who were creating the product, [but] I couldn't get anybody to fund us," Widenius said.
Before being bought by Sun for an astronomical amount of money (1 billion $), MySQL was profitable but in the range of few tens millions per year. You don't meet every day somebody putting billions on the table...
My question is: what would force a company to pay for a product if they can have it for free? I guess RedHat owners asked themselves the same questions when they practically closed the RHEL product line source code, moving the community toward the Fedora project. And now RedHat is making an huge amount of money from a product that is, by all means, the (almost) closed version of an open source effort.
So, it is really hard to build open source products, like RedHat or Alfresco, for example, because, despite all the efforts to justify a dual licensing model, you cab grasp only a very small percentage of users available to pay for a commercial edition of any open-source software. Stressing the fact that going into production requires paid support can be helpful, but it's very hard to demonstrate where the break-even is. Somebody coud argue: is that product so buggy that I need to pay a lot of money for support? Very few companies have been successful in this.
Instead of selling standalone products, I see an easier path in building solutions and services on top of an open source ecosystem: companies and their developers collaborate in growing a set of tools, frameworks, libraries with an open source development model and communities. This allows to dramatically decrease R&D costs, sharing the benefits. Today I could build a whole enterprise platform with open source software only, from the operating system to middleware and client applications, probably with better quality than a closed counterpart. But, as Widenius seems is learning the hard way, building an open source product and having paying customers is a different story: not impossible, of course, but very hard.
Widenius again: "Open source is successful for OpenStack where you have a consortium of companies that are all putting money into developing it."Exactly what I mean: join to develop the common parts, share the costs and then compete in selling some unique services. But a stand-alone, open source product, created and supported by a single company, is a different story.
Before start designing a RESTful API, have a look at Hypertext Transfer Protocol – HTTP/1.1, section 9»
In this example I'm working on a simple Web application in Flask, which is a cool Python micro-framework. I created a "flask_sample" folder which contains the code I want to version with Git and share with other colleagues.
I promised it will take less than 5 minutes, so let's start.
Move to your Dropbox folder (in my case it's in /Users/mturatti/Dropbox/) and create a folder to host all your remote git repositories:
$ cd /Users/mturatti/Dropbox/
$ mkdir git
Then create here the folder to host this remote repository:
$ cd git
$ mkdir flask_sample.git
$ cd flask_sample.git
It's time to create a bare Git repository:
$ git init --bare
You'll see it creates a structure similar to the following:
mturatti:~/Dropbox/git/flask_sample.git$ ls -l
-rw-r--r-- 1 mturatti staff 23 9 Nov 18:38 HEAD
-rw-r--r-- 1 mturatti staff 112 9 Nov 18:38 config
-rw-r--r-- 1 mturatti staff 73 9 Nov 18:38 description
drwxr-xr-x 10 mturatti staff 340 9 Nov 18:38 hooks
drwxr-xr-x 3 mturatti staff 102 9 Nov 18:38 info
drwxr-xr-x 11 mturatti staff 374 9 Nov 19:09 objects
drwxr-xr-x 4 mturatti staff 136 9 Nov 18:38 refs
Now you have in place a git structure which can act as a shareable remote repository, even if in practice it's local to your hard disk. Being a Dropbox folder will do the magic in terms of backups, sharing and synchronization.
Initialize Git in your software project as usual (in my case the local project stays in /Users/mturatti/src/flask_sample)
$ git init
This creates the usual hidden .git folder.
The last configuration step is to add locally the previously created remote Git repository:
$ git remote add origin file:///Users/mturatti/Dropbox/git/flask_sample.git
Note we are using the file:// protocol for the remote Git repository here.
If you check the content of .git/config file you'll see the new origin (in bold below):
mturatti:~/src/flask_sample$ cat .git/config
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = false
url = file:///Users/mturatti/Dropbox/git/flask_sample.git
fetch = +refs/heads/*:refs/remotes/origin/*
At this point you can start the usual Git lifecycle. For example, after you have added and committed all your files locally, you can "push to origin", which will push your code to your remote Git repository saved on Dropbox:
$ git push origin master
The last step will be to share the Dropbox folder with your colleagues, so that they can also add this as a remote repository and start cloning / pulling / pushing from this origin.