BoF to learn how to review code contributions on Thursday 26 August 2010 at 16:00 at DrupalCon Copenhagen.
At the Core Developers Summit on Sunday (22 August 2010), webchick gave a presentation about the CVS application process and what was wrong with it and what was valuable and needs to remain (there's a video somewhere of it). One of the impetuses for this talk is the git migration that is happening for the drupal.org infrastructure, because it offers us an opportunity to rethink our code contribution application process (aka CVS application process).
The agreed upon process is not a complete upheavel of our current mechanism, but does help address a few issues. I am sure there will be some issues created, but the basics are the following:
Basically what this helps resolve is that drupal.org will be able to offer a very basic place for anyone to store versioned code with very little barriers, instead of code being put on something like GitHub. This also will mean that code can have most of the drupal.org project features, like queues, and can be reviewed a lot more easily. But we still will need to review code to allow for users to create real releases.
In just a few short days, DrupalCon Copenhagen 2010 will begin. I am super excited, especially since I was really fortunate enough to get a scholarship from the Drupal Association. I am still a bit weary of the possibility of being stranded because of a volcano again.
There is a lot happening in the Drupal world around geospatial-related technologies and putting a sense of place to data (I never know the right term to encompass all that). And fortunately, there are a couple of geospatial related events going on at Copenhagen, and hopefully lots of ad hoc discussions in the hallway. No matter your expertise, if you are interested, please come on out, and feel free to stop and ask questions (though I can't promise I have all the answers).
Myself and Thomas Turnbull will be giving a presentation on Mapping in Drupal with OpenLayers which will focus on giving an overview of how the module works, alongside a live demo of the cool functionality that this module offers. It will be focused for mostly people that have not used the module before, but given time will discuss some architecture as well.
You can even get a sneak peak at the presentation on GitHub (not finished yet). You can also put together your own demo site with the module, make, script, feature set extravaganza on GitHub.
The presentation will be 25 August 2010 at 13:30 in the VPS.NET room (right after Rasmus' crowd-sourced keynote).
I have also reserved a BoF space to discuss the state of Drupal and geospatial things. It'll be a very open discussion, but ideally we will focus on the following:
The BoF will be 25 August 2010 at 16:00 in the BoF Space 4.
I have the great honor of attending DrupalCon Copenhagen in a couple weeks, via a scholarship again! I am still mad for missing DrupalCon San Francisco a few months ago due to a stupid volcano. Like in SF, there is a Core Developer Summit, and like before I have put together a basic set of slides to address a simple, but important topic: The unwieldy issues with up to 400+ comments. Embedded presentation below:
Drupal 6. Please note that most of this is sound advice but that some of it is still being debated as far as what is best practice, specifically how to ensure that exportable structures are translatable. I encourage you to leave and read the comments.
t()If you have written a module, you should be familiar with t(). Almost every interace string you write in your module should be wrapped with t(). This function creates a mechanism so that the core module, locale, can offer translations for non-English languages. Without using the t() function, Drupal would have no idea what strings are translatable and this would be very limiting for sites that were not in English (or not just in English).
The limiting nature of t() is that there is no identification on strings. This means that Drupal is not really keeping track of changes in a string and there is no way to remove old strings that are no longer needed on the site. This is a bad thing for user-defined strings, strings that are entered into the interface, for example the title of a menu item, since it can change often.
The i18n module (i18n is used based on the number of characters in the word internationalization), offers a set of modules to make Drupal a much better platform for multilingual sites. It offers the ability to translate some of the main structures of Drupal, like menus, taxonomies, blocks, and variables, as well as a more usable interface for translating.
The i18n module also offers a mechanism for translating strings that are based on identifiers for strings. The i18nstrings($name, $string, $langcode = NULL) function allows for better management of user-defined strings.
Though this problem is solved in core, it is still valid to point out in all of this. Interface strings (and other messages) that are defined in code, need to be translatable.
Interface strings and messages that are inputted by the user need to be able to be translated. These almost always live in the database. The main issue here is that there needs to be a mechanism to identify each inputted string so that changes can be maintained properly.
With modules that utilize a flexible plugin architecture or other dynamic system, one big issue is how to track what fields (or other data points) need to be translatable. This is very important to ensure that making something translatable is not hard-coded.
Recently (well, Views has done this well for a while), there has been a lot of work towards making Drupal structures that have the ability to be imported and exported. The main benefit of this is that it allows for setting-type structures to live in and be maintained in code. In turn, this means that a data structure that may contain interface strings and messages can be stored in either code or in the database.
I have always dreamed of going into space. I often ask people if they would go out into space if given the chance; I think it gives a small bit of insight into someone's personality. I doubt I will be able to make it into space in my lifetime, though I think it'll be close. But, if I can't go, this site can still move to Mercury.
Pretty cheesy intro, I know. What this actually means is that I just moved this site from being hosted at DreamHost to Amazon Cloud AWS with Chapter Three's Pantheon Mercury. The main reason to do this was performance, but I will discuss the pros and cons of this switch below.
I have done some very basic benchmarking with AB (Apache Benchmarking). By no means is this a rigorous test, but it does add some insight into the performance increase. I ran ab from a third-party server that had more consistent bandwidth and each test is for the homepage; I am running a small (default) instance. A very rough way to read all this is to say I get 50x the performance with Mercury.
| Test and Metric | DreamHost | Mercury | Increase |
|---|---|---|---|
| ab -n 100 -c 10 | |||
| Failed requests | 29 | 0 | ~2,900% |
| Requests per second | 0.98 | 19.81 | 2,021% |
| Time per request | 1024.6ms | 50.490ms | 2,029% |
| ab -n 1000 -c 10 | |||
| Failed requests | 321 | 0 | ~32,100% |
| Requests per second | 0.87 | 41.09 | 4,723% |
| Time per request | 1150.489ms | 24.335ms | 4,728% |
| ab -n 1000 -c 50 | |||
| Failed requests | 7 | 0 | ~700% |
| Requests per second | 44.86 | 112.15 | 250% |
| Time per request | 22.292ms | 8.916ms | 250% |
| Average | |||
| Failed requests | 119 | 0 | ~11,900% |
| Requests per second | 15.57 | 57.68 | 370% |
| Time per request | 732.46ms | 21.91ms | 3,343% |
| Increase average | 5,204% | ||
Here it is: my simple, unexciting, unoriginal slides on how we need to get Block Instances in Drupal core.
I have recently discovered the great joy of reviewing CVS applications for Drupal. I am serious, I love looking at code and directing Drupal developers early on into using Drupal Coding standards and best practices for Drupal development. I have also noticed a number of similar things, so I would like to write a quick post about some basics as to creating a Drupal module that can get a CVS account.
Please note that, these are not necessarily a part of the CVS Application Requirements, and I do NOT speak for the Drupal Infrastructure team or other reviewers of applications. This is just things that I notice and suggest when I do my review, and I feel are important when creating and contributing a Drupal module or theme, a lot of which can already be found on the often-overlooked things to expect (and I should add to as well). Also, I am quite aware that my code is not perfect, but that does not mean I am not capable of directing people in the right direction.
It may be good for perspective to tell you that, honestly, I don't even install the module that I am reviewing most of the time; I just look at the code. I make the assumption that if you are sharing it, you have already used it and tested before applying with it. In some people's eyes, this may seem irresponsible, but I feel it is a safe assumption to make.
As the number of contributed modules continually grows on drupal.org, it is more and more important to ensure that new contributors have proved that they have looked at other modules and can describe what their modules do accurately.
Today is Ada Lovelace day; the goal of today is to blog about great women in technology. Ada Lovelace is often considered the first computer programmer, and as someone who loves to code, that's a pretty big deal.
I would never consider myself an activist, but I have always been concerned with gender issues in our societies and specifically with technology. I think it's very important to ensure that everyone is treated equal and with respect no matter gender or other qualities. I think by encouraging and supporting tech minorities, such as women, our community can only be stronger and more valuable to ourselves and others. So, I am happy to write on this subject, even if my body says go to sleep.
Like a lot of posts I have read today, it is very hard to pick just one woman that has made my life, both personal and technical, better. Being a part of the Drupal community means that I get to interact with some amazing woman (and men), and it would be unfair of me to pick just one. So, I want to briefly tell you about some of the fantastic woman in Drupal and how they have made my life better and this world a better place (in no particular order). Some of these women I know well, some just in passing, and some just because of the awesome work they do. This is just a handful of the woman in the Drupal community that deserve notability and only a fraction of the contributions that they make. Remember to encourage women on our community, as well as everyone else. In my opinion, to have a meaningful community, we need to have freedom from elitism, sexism, racism, prejudice, and just general discouragement.
Thank you all for your contributions and support; my apologies for all the great people I have not mentioned. Happy Ada Lovelace Day!
Last weekend (26-28 Feb 2010) DrupalCamp Spain happened in Barcelona at the great CitiLab (pic), which is where DrupalCon Barcelona happened a few years ago. I don't have the exact numbers in front of me, but there was just about the same number of attendees for the DrupalCon a few years ago as there were for the DrupalCamp just a week ago (before and after)! Drupal is getting huge!
The camp was wonderful. The organizers did a great, professional job. Though my Spanish is not very good at all, all the presenters did a great job and had a nice variety of topics. I met lots of wonderful people, both seasoned Drupal professionals and Drupal first-timers. Unfortunately my trip was short, but I did get to experience some of the beauty of Barcelona. And, of course, there was the poll-dancing Drupal gorilla (pretty standard). Thanks for having me and for all the hard work!
I did a presentation on Understanding OpenLayers and Drupal. I think it went pretty well. I am still getting my sea legs (and by sea legs I mean ability to speak in front of people); but the room was packed, and I got to do my first Prezi presentation. I am pretty pleased with Prezi, though it took some time to put it all together and stop thinking about things so linearly.
Below is an embedded version of the presentation; it actually starts on the second point. This is a presentation based on OpenLayers 2.x which is still in development but doing good thanks to the hard work of the developers. They took video at the camp, so I am assuming one day there will be a video which might help with understanding the presentation some.
Spread the word; Chach Sikes and Erika Stenrick who work with Gorton Studios, have just announced a DrupaChix Sticker Design Contest for DrupalCon San Francisco (sponsored by Gorton Studios). This is a great opportunity for anyone to show off their design skills, and, more importantly, help support women in our Drupal community.
In case you aren't in the know, DrupalChix is an awesome group dedicated to supporting existing women in the Drupal community as well as working towards getting more women involved in Drupal. Drupal has such a great community, but we could be so much better by getting more women (and other under-represented people) involved into Drupal.
The stickers will be made in mass quantity and distributed at DrupalCon San Francisco. Designs are due in by 15 March 2009, so act quick! Post your entries to this thread. And for the non-designers, voting begins on 17 March 2010.
Unless otherwise noted, all content on this site is licensed under Creative Commons Attribution-Share Alike 3.0.
Please see the legal page regarding more in depth information on copyrights or other relevant laws.
