History of science fiction
A good map to navigate through the themes, authors and styles of the so-called scifi.
Etiquetado: English RSS Mostrar/ocultar comentarios | Atajos de teclado
-
Andrés
-
Andrés
«Just as demagogues may subvert democracy, so self-promotion may subvert meritocracy.»
Open Source Projects and the meritocracy myth -
Andrés
«Institutional memory comes in two forms: people and documentation. People remember how things work and why. Sometimes they write it down and store that information somewhere. Institutional amnesia works similarly. The people leave and the documents disappear, rot, or just become forgotten (as it were).»
Sign: an engineer. On institucional memory and reverse smuggling. -
Andrés
If you’re trying to make a successful tech product, 90% of the battle is that it works at all.
Havoc Pennington, on creating a successful product… and companies I would add. -
Andrés
Just found this online-ongoing comic by Sidney Padua created to the Ada Lovelace day in 2009. She depicts a steampunk alternative past where Charles Babagge and Ada Lovelace got to build the difference engine … to fight crime!! LOL. Here the chapters. Don’t miss this one: Lovelace and Babagge VS The economy, where they fight against the economic crisis of 1837, which has uncanny similarities to ours.
-
Andrés
«And this is the essential broader point–as a programmer you must have a series of wins, every single day. It is the Deus Ex Machina of hacker success. It is what makes you eager for the next feature, and the next after that. And a large team is poison to small wins. The nature of large teams is such that even when you do have wins, they come after long, tiresome and disproportionately many hurdles. And this takes all the wind out of them. Often when I shipped a feature it felt more like relief than euphoria.»
Dhanji R. Prasanna (one of the engineers behind Google Wave), on how even the smartests fail to stick to the essential. Jointly with this other post, they both draw a good story for any startup to hear. -
Andrés
Analysis of free software communities (III): activity and manpower
- Images: on the left, the number of changes to the codebase (commits) agregated by year. On the right, the number of developers with at least 1 commit that year.
- Data: trunk from project repositories during the period 1999-2010.
Is it something we could extrapolate from the data there?
Certainly, not the number of features developed or bug fixes. It is even barely possible to compare activity between projects, as there are a high variability in terms of changesets: some people could send several little changesets and others just 1 big change, some project could have a special policy which affect the results (i.e.: make a commit formatting the code accoring to the style rules and other with the changes), etc. Some people could even argue that the language they are written in affects the number of changes (GRASS is written in C, gvSIG in Java and QGIS in C++) due to the libraries available or the semantics of every language. So, is it possible to find out something? Well, in my opinion, we can trace at least the following:
- the internal evolution of a project.
- how a project is doing in terms of adding new blood.
So, let’s make again the exercise of finding out what’s happening here:
GRASS
- It calls the atention the curve of activity in the project: growth by periods (2001-2004 and 2005-2007) with local maximums in 2004 and 2007. Our hypothesis was that it was due to the way the project works: the developers here make changes both in the trunk and in the branch of the product to release (be it 6.4 or 6.5) at the same time, with a lot of changesets moved between both the trunk and the branches (so doing heavy backporting). In a recently conversation with Markus Neteler, he has explained me better how they work and I guess the rhythm we see in the graphics is due to that.
- In terms of number of developers, GRASS has showed a continuous growth until 2008; since then, the number of regular developers stabilizes.
gvSIG
- gvSIG shows an incredible high period of activity during 2006-2008 (4500 changesets by year and most that 30 people involved!). To understand the Gauss bell of activity, is needed to know the background of the project: gvSIG development has been led by contract, which means that all activities (planning, development, testing, etc) were led by the client needs who pay for it. Only recently, these processes have been opened to a broader community (firms and volunteers collaborating in the project within the gvSIG association). So, it makes sense that the beginnings had seen less activity (high phases of planing) and afterwards they got to agregate so many people in such a short period of time.
- But, in 2010 it suffered a sudden stop in development (only 233 changes to the codebase were made, while a pace of 4500 changes were made during previous years). This decreasing in activity is highly correlated to the number of developers involved. It’s hard to say why it happens: could it be due to the efforts were directed to gvSIG 2.0 development? could it be due to the reorganization in the project and the creation of gvSIG asociation? Well, few can we said at this respect with the data available, further research is required to determine that.
QGIS
- Steady grow both in terms of contributions and contributors. 2004 and 2008 years determine two peaks of activity and people participating in the development. Our preliminar hypothesys was that it was due to the release of the first stable version and the release of 1.0, as well as become an oficial project of OSGEO. Gary Sherman has confirmed that in a recent post (history of QGIS commiters) and an interview (part1 and part2). Besides, he pointed out that in 2007 the project added python support for plugin development, which possibly was one of the reasons of the growth in 2008 and afterwards.
- An interesting finding is that, every 4 years the project has doubled the amount of developers involved with a slower but steady growth in activity.
Well, hope these graphics have helped us to understand better how is the project activity and the manpower every project is able to aggregate around it. Next posts in the serie, will focus on the developers involved and the culture surrounding them. Looking forward to your feedback! -
Jorge
Regarding gvSIG I guess you were looking at gvSIG main repo, I don’t know. Just for the records, I want to note that gvSIG 2.0 development has been exploded to several OSOR projects and because of maven modularity there are many different locations where activity happens. César Ordiñana has been maintaining the list of repos at gvSIG Desktop 2.0 entry at Ohloh http://www.ohloh.net/p/gvsig-desktop-2/enlistments
I agree that gvSIG development has decreased in activity by “main contracts” but it’s increasing the contributions my small contracts that public administrations make to improve some specific parts of the products. I like a lot this way, as it demonstrates the maturity of understanding of public bodies decision makers regarding what free software is (pay for improvements and maintenance, not just for new ultra-cool features).
There are more to discuss here but well, it’s enough for a blog comment
Nice reports!!
-
amaneiro
Yep, the report depicts the activity in gvSIG 1.X line.
-
Andrés
I found interesting this serie of posts titled “4 big ideas in software development” according to Tim Ottinger and Jeff Langr. The serie was published monthly in Pragmatic programmers magazine:
- Code coupling, or Reducing dependency in your code.
- Cohesive software design, or Cohesion makes code easier to understand, debug, and test.
- Abstraction, or How to tell a cat from a dog.
- Software volatility, or Do most changes to your code base occur in just a few files?
Andrés
Analysis of free software communities (II): adoption trends
Find below the statistics for mailinglist activity in GRASS, gvSIG and QGIS during the period 2008-2010. The first one shows data from the general user mailinglists for each project. Take into account that data for gvSIG agregated both international and spanish mailinglist due the reasons stated here.
The next one shows the same data (number of people writing and number of messages by month) for the developers mailinglists.
Is it something we could extrapolate from the data there?
Well, certainly not the user base. The data shyly introduce us the trends, not the real user base. The model we adopted to study the projects reflects just a part of the community -which is arguably the engine of project- but don’t take the data as the number of users for each project. For sure, each one of our favorite projects has more users than those participating in (these) mailinglists!
Anyway, here some food for thought:
- GRASS: it smoothly decreases in terms of number of messages as well as people writing, which happen within users and developers. The tendency is not clear though.
- gvSIG: the data shows a steadly increasing number of users participating in the mailinglists. On the other hand, although it is the project with more people suscribed to developer mailinglist, it shows the less activity of the three projects (in terms of # of messages in developer lists): few technical conversations seemed to happen through the mailinglists during that period.
- QGIS: according to the data, a clear growth exists in the community. In the period in study (3 years) the number of users and developers participating in mailinglists has been doubled!
Few more can be said, hope the graphics are explicative enough! Looking forward to your feedback.
Andrés
How gvSIG MapControl works: flow of control
Within gvSIG design, MapControl is one of the core components. Its main responsibility is to allow users to interact with a map of layers (zoom in/out, edit geometries, …). That goal is achieved through two concrete tasks:
- Route the user actions to the proper tool which will execute it.
- Manage the drawing of the layers.
This post covers the first of above tasks in an introductory way.
Flow of control
MapControl is a java component, which uses the idea of Chain of Responsibility to delegate work on others. Let’s see how it works in this case with a good old graphic:
- MapControl listen MouseEvents through the MapToolListener. In response to an event, the MapToolListener will call the active tool (let’s say this class is named Behaviour).
- The active Behaviour processes the info from the mouse, put together the contextual information needed (let’s call that an Event) and calls the next step in the chain (let’s call it the ToolListener).
- Finally, the ToolListener will execute the actions needed to carry on the task an user have asked for.
Some notes before digging into code:
- MapControl can have only 1 tool (Behaviour) active at any time. It holds the current selection in a private variable: Behaviour currentMapTool
- MapControl wraps MouseEvents in 4 basic canonical events (see com.iver.cit.gvsig.fmap.tools.Events within libFMap project): MeasureEvent, PointEvent, MoveEvent and RectangleEvent. Any other event will inherit from and extend one of these canonical forms.
A concrete example: how a move event is processed
1 – MapToolListener: listen the mouse event and proxy it to the current selected behaviour (currentMapTool variable).
public void mouseReleased(MouseEvent e) {
try {
if (currentMapTool != null)
currentMapTool.mouseReleased(e);
} catch (BehaviorException t) {
throwException(t);
}
}
2 – Behaviour (MoveBehaviour in this case): takes the event, put together the context (MoveEvent) and redirects the petition to the proper ToolListener (listener variable).
public void mouseReleased(MouseEvent e) throws BehaviorException {
if (e.getButton() == MouseEvent.BUTTON1 && m_FirstPoint!=null) {
MoveEvent event = new MoveEvent(m_FirstPoint, e.getPoint(), e);
listener.move(event);
}
m_FirstPoint = null;
}
3 – ToolListener: carry on the task. In this case, the listener (a PanListener) make the viewport to update the extent with the new contents.
public void move(MoveEvent event) {
ViewPort vp = mapControl.getMapContext().getViewPort();
Point2D from = vp.toMapPoint(event.getFrom());
Point2D to = vp.toMapPoint(event.getTo());
//build the new extent
Rectangle2D.Double r = new Rectangle2D.Double();
Rectangle2D extent = vp.getExtent();
r.x = extent.getX() - (to.getX() - from.getX());
r.y = extent.getY() - (to.getY() - from.getY());
r.width = extent.getWidth();
r.height = extent.getHeight();
//update the ViewPort
vp.setExtent(r);
}
Coda
Some useful resources about MapControl in gvSIG wiki:
- MapControl (spanish)
- Behaviour (spanish)
- ToolListeners (spanish)
- Events related to toollisteners (spanish)
Links to code:
- Mapcontrol
- Canonical events of MapControl:
cesare 18:33 el 7 octubre, 2011 Enlace permanente |
Hi, very interesting post! Only a question: where do you foind the data taht you’ve used in the charts?
amaneiro 17:29 el 8 octubre, 2011 Enlace permanente |
Hello Cesare, the data comes from the code repository of every project. We parsed it and generated the stats. If you are interested in playing with them, find them here.