A barn raising is an event during which a community comes together to assemble a barn for one or more of its households, particularly in 18th- and 19th-century rural North America. (Wikipedia)
The same can be done for websites.
SCALE, the Southern California Linux Expo, is going to be a little earlier next year and this has moved forward the CFP (Call for Papers). We will be building the SCALE site on Drupal 7 this year.
In the past, the CFP was on a separate non-Drupal framework and importing the data was the source of some headaches. I hope by bringing the CFP into Drupal from the start, we can improve on that situation.
What we have now:
- We're just starting out!
- By the time of the event, I will create a Git repository with a base install and database.
- I have screenshots of the old forms for reference.
What we need to accomplish:
- Set up the site to accept submissions for the CFP (call for papers)
- Work out the basic arrangement of data need to be captured and how it's shared/coordinated
- Create some content types: Speaker, Presentation
- Put as much configuration into Features as possible
- Create some basic pages: I should have the text for the call for papers page in a few more days
- Choose a base theme and do some light themeing
This website is using LDAP authentication and authorization and I had thought that would create some problems but I just heard that we will able to register new users without LDAP. That is going to make our task a lot easier and give us more options.
If you would like to participate help get the SCALE 10x site off the ground, please sign up. This event will be limited to 15 people. I would really appreciate it if attendees can stay for most if not all of the event. Getting up to speed may take some time and doing it multiple times will be disruptive.
If you will attend, please sign up and come with a the site installed on your development system. I'll post instructions here on cloning the repository soon. To access the repository you will need to send me your SSH public key.
Food will be served.
Location
Droplabs
651 Clover St.
Los Angeles, CA 90031
Droplabs is in the Mission Junction neighborhood of Los Angeles at Big Art Labs, just 1 mile down Main St. from Philippes (the first-ever venue for LA Drupal meetups!) and Union Station. We're one block west of The Brewery, the largest live-and-work artists' colony in the world.
What to bring
Just bring your laptop, your business cards or whatever else you need. We share a large parking lot with Big Art Labs and there's plenty of free parking. After you pull into the parking lot, park to the left of the entrance and follow the signs to Droplabs.
Please note that our guest wireless network is limited to 1Mb per client, so bring your MiFi router or a phone you can tether with if for some reason you need a lot of bandwidth. Access to our high-speed network is included with a Droplabs membership.
For any changes to our agenda, stay tuned to this meetup announcement or click the Sign up button below (or both!) to be notified when the agenda has been updated. To get last-minute updates, follow @Droplabs on Twitter at https://twitter.com/Droplabs or find us on Facebook at https://www.facebook.com/DroplabsLA
About Droplabs
Droplabs is a collaborative Drupal event and coworking space in Downtown Los Angeles. Created in 2011 by LA Drupal members for the LA Drupal community, we are focused on serving the greater LA Drupal community, enriching the Drupal skills and lives of its members, and bringing joy to our Drupal practice.
We've been open to the public since May, 2011, and the use of our equipment and facilities, including conference room, tables and chairs, is free until our official launch. See http://groups.drupal.org/node/145934 for more details about our open beta period and http://droplabs.net/prices for our list of free amenities and member perks, including our high-speed WiFi, an espresso machine, printer and scanner services, and more.
Droplabs is the host of the monthly Downtown LA Drupal meetups, LA Drupal's weekly Pro Drupal 7 Development book study group and special events including the Varnish 3 Release Party and LA Drupal's first-ever Drupal job fair. To learn more about Droplabs, follow @Droplabs on Twitter, sign up at Meetup.com/Droplabs or like DroplabsLA on Facebook!
About LA Drupal
LA Drupal is one of the world's largest regional Drupal user groups and is Southern California's largest hub for all things Drupal. In addition to scheduling 4 regular meetups a month and occasional trainings and social gatherings, LA Drupal members produce special events, code sprints, and the annual DrupalCamp LA and Drupal Design Camp LA conferences.
Attending LA Drupal events is one of the best ways to meet and talk with other Drupaleros and we encourage you to attend meetings and special events regularly. Whether it's to find solutions to problems you've been having, sharing something you've learned or just meeting interesting like-minded people, the LA Drupal events are an essential resource for Drupal professionals and hobbyists alike.
If you aren't already part of LA Drupal, it's easy to become a member and find events in our community calendar at http://groups.drupal.org/la/events
Comments
WOW
(jaw drops to the floor)
JUST PERFECT that I'm in NY while this is happening.
DAMN DAMN DAMN...
i JUST got into Linux and it is changing my life. What I would not give to be able to attend.
Can I help out with design in any way?
Great Time
Thanks to everyone who made this happen. This was my first sprint and as I'm not a dev I was pleasantly surprised at not only how much I got to learn but also how there were ways in which I could contribute as well [ie. making food run =)]. Kidding aside it was really insightful watching and participating in the 'process' of getting things done. Again thanks to everyone who took the time to answer all of my questions - people like you make learning Drupal fun.
A few of us will be working
A few of us will be working more on the site during the Users Helping Users part of the Westside meetup on Tuesday:
http://groups.drupal.org/node/162814
If there's interest, we can also do a talkback later during the meetup of how the barnraising went and what was learned about Drupal 7. For example, I was surprised to see that only 2 modules we installed actually had full release versions (i.e. 7.x-1.0 instead of 7.x-1.0-beta1).
SCALE Barn Raising Meeting Minutes
www.LADrupal.org sponsors
www.SocalLinuxExpo.org CFP Barnraising
July 23, 2011
Meeting Minutes
By Peter Benjamin
Ron Golan ran a wonderful Barnraising. I've been writing Meeting Minutes for a couple weeks now. Today, I realized there are two reasons. The first reason, I knew about before, is to provide those not fortunate enough to attend and get the presented resources. The second reason, very true for the barnraising, is what "stages" were involved, and give expectations to potential first timers of what to expect, in hopes more will come and receive 'extreme' value for time spent.
These Minutes will not cover "resources" as much as what happened, and why I consider I got, not just good, but great value, for my time. It felt good to be one of the more expert Drupalers. It was good to donate my effort to a worthy Open Source cause, the largest Linux Conference run by Open Source advocates, all volunteering their time.
Do attend each and every annual www.SocalLinuxExpo.org - the next is January 20-22, 2012 at the Hilton Los Angeles Airport. If you think this barnraising is of value, then SCALE is certainly for you. In fact, submit a paper! (Disclaimer: This barnraising was to assist the integration of the main SCALE web site with the Call For Papers, CFP, submission engine.)
Also, come to our www.DrupalCampLA.com in two weeks. Extreme value, training and networking, is available in just one weekend. There will be dozens of sessions to chose from, both days, each session lasting 45 to 90 minutes.
Editor's note: I thought these minutes would be 1 page or so. My bad they got long, maybe my longest, but I think many readers will find value.
Great Value!
Does your computer have a working LAMP stack? git installed? Working Drupals? Do you know the steps in designing a Drupal web site section from scratch? Defining a new content type fields to the web site database for display to surfers? How to create them? How to test the input form display? Re-arrange their display order down the page? Put in test data? View this test data? Create a View to make a list of the new nodes? Change the View's displayed fields? Pull in data from other node types? Enhance the User Profile with more fields?
Do you have a distributed development environment on multiple computers for your team to create a complex web site with? Able to individually create "features" and integrate them to a central checkin library with a few clicks? And redistribute those changes back to the team computers for integration testing of the next iteration of complete package? In just a few mouse clicks? And such an environment could be used by a sole developer (or team) to stage features for testing and promotion to the production web site. And it comes with "branches" and "roll back" capabilities? Thus, allowing testing of potentially better implementation directions, and providing the ability to merge the best branch, or back out all changes?
How would you set such up? (Hint: Read these Minutes.)
Is that enough to make "great" value? I think so.
Get yourself to the next Barnraising or Code Sprint!
Now, SCALE's CFP Drupal web section is a step closer towards having an uncentralized development team, as well as the SCALE main web site, over the coming years. Nine development computers now have git access to CFP implementation and testing. I see in the future, 20 to 30 SCALErs will contribute to the 'dev' web site repo, be able to test in the 'staging' repo, and Ron will promote from the staging repo to the public site's repo. Or similar.
Now, for those www.LADrupal.org members whose home or office computer has yet to be set up to run Drupal, these Minutes are a RoadMap to doing so. Roll your own, and post to the http://groups.drupal.org/la website a new "Discussion" to ask your support questions. Or ...
Go to 3 to 5 Barnraisings or Code Sprints and your level of expertise will rise right up that very steep Drupal Learning Curve. Code Sprints can do the same, just in a different way. Code Sprints need the first set of Stages below. The second set of Stages below is for SCALE.
For PHP programmers, Code Sprints' second stage is learning Drupal Core and Module Issue/Bug patching/fixing methods. Code Sprints are of great value going up the steep Drupal Learning Curve.
Barnraisings and Code Sprints needs all levels of experience. There is lots to do. And lots of assistance. Best of all, the chosen design and implementation direction is going to be superior compared to a sole individual doing all the brainstorming. An added benefit is more minds means the web site is a multi year solution, that grows easily with new requirements, rather than go all spagetti, filled with deadend algorithms, and high maintenance chores.
For those wondering how easy it all is - yes, it's easy - I present each stage's steps briefly, with enough detail, to convince one to get to the next barnraising. These minutes are from my perspective, covering my experience, while other break out groups I did not participate in, those barnraisers will have had other experiences, that I can not document. However, I can set your expectations of what happens at a barnraising.
Outline of Stages
These Minutes are not intended to be a Step by Step, but to show you how easy it all is. These Minutes are specific to this SCALE barnraising. Places where we had troubles have their solutions pointed out. The Stage order is not fixed, but this order does work.
The below steps are specific to what we did at the meeting, for SCALE CFP.
Each Stage may have 1 or steps, which I include below.
I'm not going to cover installing a LAMP stack. Most all barnraisers' laptops already had that. Some laptops were running more than a half dozen test web sites, client development sites, personal staging sites, etc. Well, one had a broken MAMP stack, which can be sticklers to get working again. AMP installation instructions abound online.
Whose computer needs enhancement?
All attendees' computers are looked into and needed software is installed, thus creating a teamwork environment, able to code individually, and rapidly set up integration testing within 20 seconds. You do not know how to do this? We do. Come to the next barnraising, get the environment, and learn how. This can take about one hour for troublesome computers (Windows and Mac, not Linux;^) I did it the night before in 20 minutes. Drupal project Features combined with git makes this all possible.
An AMP stack (Apache, MySQL, PHP packages) is installed. Also, known as LAMP, WAMP or MAMP stacks for Linux, Windows or Macintosh, respectively. Other OSes can run Drupal, just find online instructions. The web server does not need to be Apache, but it's easiest, having the Drupal required module 'rewrite' that supports Friendly URLs, but IIS or other web server software can work with Drupal. The database software can be one of five known to work easily with Drupal. Both Apache and MySQL are large downloads, and should be done the week before. PHP is required by Drupal. Drupal is written in PHP and will not work with any other language compiler or intepretator.
The next few outline bullets document the needed stages to set up.
ssh-keygen for git
For those wanting to get into the action of using a central git repository (checkin/out library), first create a ssh key pair, a two file key, where the public key goes to anyone, like the git repository, and the private key goes into your .ssh/ folder. And keep it PRIVATE! Make a back up copy of it. If you lose it, then it's 10,000 years to crack any file encypted with your public key.
Create the two parts of the key pair, the public key, and the other half of the key pair, decryption key, or private key, with one command. You may get some extra clarifications here: http://help.github.com/linux-set-up-git/
Ron emailed attendees the "git clone" command to use, when I had sent him my ssh public key the night before. I made my key with these commands. Note, the file name has an extra part '.scale', so I did not overwrite my default key. This different file name means I must add to my ~/.ssh/config file to point to this "IdentityFile" filename. Easily done as shown below.
$ cd /home/user/.ssh$ ssh-keygen -t rsa -C "email_address" -f id_rsa.scale
which outputs the below, where you need enter your decided ahead of time passphrase, twice, which is entered without displaying the typing as a security precaution (bolding is mine):
Generating public/private rsa key pair.Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa.scale.
Your public key has been saved in id_rsa.scale.pub.
The key fingerprint is:
##:##:##:##:##:##:##:##:##:##:##:##:##:## email_address
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
| = . |
| o E + S |
| . + O = O |
|o . O . . |
|.o + * . |
| = |
+-----------------+
where you enter your 16+ character passphrase you will NEVER forget, and you need to use it each time you git. Ok, it's not that bad, but asking the admin to replace your key ... gets old fast.
Yes, it's easy. Try to have this done "before" the barnraising, and send the "public key", the filename ending with ".pub" to the admin running the git repository. The admin will install the public key, so git sends and gets files with encryption over the public network, and you do not need a password to the repo, the private/public key replaces the library password.
I added the non default git port number for this SCALE10X repo in my /home/user/.ssh/config file
Host unbuilt.orgHostName unbuilt.org
IdentityFile ~/.ssh/id_rsa.scale
port #####
Compression yes
CompressionLevel 9
LogLevel VERBOSE
For security reasons I hashed out the port number value. If this port number is blocked by a gateway firewall, well then, try a different wifi SSID. The symptoms are the git command never shows any progress, not even asking for your passphrase.
The last three lines are personal preferences, for faster, smaller downloads. VERBOSE can be changed to DEBUG3 if you want all the log messages, to troubleshoot with. One can not 'git clone' the repository to the local hard drive, to test the git/ssh/key set up steps. More on git clone below. First, set up the local web server.
Configure web server for new web site at it's domain name
There are two stages needed dealing with /etc/hosts (all Internet machines have this "hosts" file - the format is identical on all OSes) and /etc/apache2/sites-available/domain.name.conf, or the equivalent for the computer's Operating System. /etc/hosts gets one extra line like this:
127.0.0.2 scale10xPretty simple. The domain name created is "scale10x" and resolves only on the local computer, not on the big Internet. A hard concept for some to understand. Also, hard is there is no top level domain, TLD, that is, no .com, or .org, or .net involved. It's only on one computer, so it works.
For the web server config changes, well, details are not included in these Minutes. There are many online sources for this information.
git clone to fetch repo files to webroot
Now, you are ready to git clone (get) the repository, which takes about 30 seconds on a broadband connection. Create a folder to hold the new directory tree that git clone creates. The folder pathname will be used to config the web server. The pathname should be inside the "web server root folder," which varies based upon OS and web server install defaults or config tweaks.
mkdir /var/www/htdocscd /var/www/htdocs
git clone gitosis@unbuilt.org:scale10x.git
Looks alot like an ssh/scp/sftp/rsync command. The command 'man git' will show you the syntax as:
git command userid@domain.name:repository.nameThis commands installs a complete top level folder with the web root in folder httpdocs/ and extra folders for special purposes. Now, sometimes instead of CLI (command line interface), one might use a GUI (graphics user interface), so one mouse clicks on buttons for all git commands, and types less.
Inside this folder is a hidden directory named ".git" that contains git configuration files, so future invokations of the git command from this folder, the last part, userid@domain.name:repository.name, is no longer necessary, only "git command." To get new updates from the central repo type:
git pullSay what? Is that all? Yes, that logs in the repo, using the ssh key, examines web root tree file differences, fetching only the new and updated files, copying them into the web root. The database tables are NOT involved. Except, Drupal project Features is being used to load certain Drupal database values into web root files (all/modules/contrib/features/*) so SOME (most) database values can utilize the 'git' file repository system. Cool! Drupal module "Features" not only can install packages into other Drupal sites, but can migrate some database values, and be used with git for uncentralized team development.
Finish Drupal Set up
After the first 'git clone' command, the typical Drupal install steps need to be done. See INSTALL.txt. The database 'name' is created, and the database userid, password created with GRANT SQL command. Copy default.settings.php to settings.php, open up write permissions to include the web server process user id, and change the database values to use in settings.
Now, with your web browser go to the new /etc/hosts "domain" name or IP number, and run the Drupal install.php script and it's many steps. Your initial, cloned, local, SCALE, Drupal web site is installed and running in under 10 minutes.
Oops, a small mod_rewrite hiccup resolved
As the initial git repository was distributed with a Drupal database with "Friendly URL" enabled, apache must have module "mod_rewrite" enabled, If its not enabled, then logging into Drupal results in a web server log entry of
Not found /node?destination=nodeand the page does not appear to change at all, though you are logged in (see the database table 'session' entry). To enable mod_rewrite, create a softlink like so:
cd apache2/modules-enabledln -s ../modules-available/rewrite rewrite
where your web server configuration might be different. Restart apache with 'apache2ctl restart' command. Now, Drupal will work fine. Now, with the team developement infrastructure in place, the fun Design and Implement stuff could begin,
Designing The Required Web Features
Put away the computers. Talk. Brainstorm. The requirement was to duplicate the existing SCALE CFP submission web engine, meaning view it's input pages, and design equivalent Drupal content types. This part went fast. And it drove the next stage, the question could Drupal's core do everything, or would add-on modules be selected, and which ones. With Drupal 6 the choices were obvious, but with the Drupal 7 requirement, it was a game changer. A learning curve for everyone, even the experts.
Much discussion focused on two areas, the user profile of the Speaker submitting the paper and the relationship between the Speaker and the Presentation meta data (description, target audience, skill level, etc). There were two modules discussed for Speaker profile. Many pros and cons were discussed. The expert exchange was a good learning experience for those new to Drupal. Profile 2 module was not used, initially, but by using git branches, both modules were able to be experienced within the hour. A final decision was not made, but it looks like Profile 2 will get the nod. The user experience was the big difference, the existence of a Profile 2 "local task" menu "tab" that might 'hide' the additional fields from having the Speaker enter values.
Now, I was reaching 'information overload' after so many hours, so I agree, all mistakes in these minutes are mine, particularly below.
The Paper Submission or "Presentation" information was easily gleaned from the existing CFP engine. However, there may have been more brainstorming selection of how to relate this information to the Speaker and any Co-Speakers. About 20 'relationship' modules were mentioned, before settling the decision to try a new one, CNR, in Drupal 7.
Implement features as new Content Types
For this Stage there was a break out into small teams of two. Each two person team got a feature to implement using the design approach. The fun truly began as creation resulted in completed features. Questions were addressed to Ron, who made decisions, or due to the complex nature called in the needed experts to discuss and answer and give final direction to the team. It went quickly. The Speaker (Drupal user) Profile database fields were created and tested. The Presentation (Drupal Content Type) fields were created in under 30 minutes and tested.
These two new 'features' then were 'bundled' using a special Drupal module called "Features" www.drupal.org/project/features The bundle could then be git commited and pushed to the central repo, so all other teams could 'git pull' to install the feature in their dev environment. Takes about 1 to 5 minutes to use the Features interface to create the new module, yes this Feature modules makes modules to hold all the subfeatures and most database values, and 1 minute to git commit and push, and as fast as you can type 'git pull' to distribute the new entries in the central repo. Wonderful!
A decision by the Profile team was made to try a different method, a git branch was created, this new Feature was git pushed, the old Feature was removed, and the other 8 dev computers did a 'git pull' to have the old Profile removed, and the new Profile installed. The old branch is still available in the master repo in case the decision to try it again is made.
As we were wrapping up this Stage, a point was reached where extra design choices could be made. That is, could we enhance the new CFP submission engine with better fields, new fields. The decision was some areas could be enhanced, but we did not have time to itemize them and start their design. Later discussion with the SCALE Requirement Team would lead to changing the Taxonomy Vocabularies and Terms, still in progress. Expectations are new Selection Pulldowns and their Terms will be added to the Submission Form. The new choices should take a dozen minutes to add, and a dozen more to test. That is so quick means changes may be made right up to the moment the CFP engine goes live. Preferably, the changes are finalized a day or more before going live. Drupal is that easy to change, and do so with little testing (not in all cases, but many). Agile programming at it's best!
Add Views for lists of the new Content
There is no doubt that Views are complex. Both in scope and it's user interface. It's power is awesome. All CMSes are now implementing similar SQL generators. Drupal is on the leading edge in "click" SQL generation. Drupal 7 release made some improvements, but in doing so hide some of the power, but most users will like the two big shortcuts, a one page wizard, to make default displays for "Page" and "Block", the most common View Displays.
I'm not going to explain the hour we spent doing this last stage with Views, as it does not lend itself to easy paragraphs. I will highlite some things.
The wizard did not allow for using zero for unlimited entries on the page or block. However, it could be changed inside the Views GUI. I'm thinking it's either a desire to limit run away CPU/IO usage in making monster long pages, a good thing for a wizard to restrict early learners from, or there is one or subfeatures that do not permit unlimit entries per page or block. Some homework for a guru to find out and report back to us.
The "add fields" sub feature did not list "all" possible fields like it did in Drupal 6. The list was limited. By using the sub feature "Relationships" and selecting other content to include (in our case the user and Profile 2), the "add fields" selection list expanded, double in size. Drupal 6 Views was criticized for too large a field list, and many fields did not make sense. This criticism is addressed, and a more powerful "Filter" field would do a wildcard match to reduce the list size, to prevent excessive scrolling in a tiny select list window of hundreds of fields, down to just a handful. Nice!
Thank You's
This barnraising was sponsored by SCALE, who provided lunch from www.CowboysAndTurbans.com Indian pizza - can you believe it? I'll be stopping for dinner there before future Droplabs events. Their Tandoori Chicken Quesadilla ... yum.
Hosted at www.Droplabs.net courtesy of these four owners Ron, Lee, Christefano, and Paul. Droplabs supplied coffee and beverages and atmosphere. Droplabs is a Drupal Hacker Space whose grand opening still continues with free access for another month, or so.
And many thanks to Ron Golan, the Master Of Ceremony, who ran a gracious event.
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Features does not enable modules, likely as it's not enabled.
I just git pulled to a new machine, and found none of the needed modules were enabled. I'm thinking this was due to Features being disable, or the Features built modules (4 of them now) being disabled.
Point is, new barnraising members should be told to enable modules after their first 'git pull.'
Pete
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE
Why Features is doing Terms last - module scale_terms update
During the meeting it came up why Features did not include Terms, as it ought to be quite easy. In our context of creating "new" Terms for git, it is easy. I postulated it was harder than that, as what if, inside the Feature the taxonomies defined were already present in the receiving system's database tables?
I can see many conditions, quite complex, that would need user input to resolve some of them.
A Vocabulary name could exist in the receiving database and different conditions could exist, such as:
1) More terms - simple - just add the new ones
2) Fewer terms - delete some?
3) Typo corrections, closely spelled ones
4) Contains a hierarchy - delete it?
Just to name a few off the top of my head.
But worse, what if existing nodes referenced those Terms? Delete a term that is in use? Delete an entire hierarchy subtree?
I shudder to think what type of solution, manual intervention, must be coded up to handle all possible combinations and permutations of what might be found in the migration. It's going to be messy!
While Ron email me after the meeting the Terms were changing, and maybe more select lists added, I've continue to code my module that will "add" new terms, and included an Uninstall. I've decided to make afunction utility of the Uninstall taxonomy_term_delete loop, so it can be called during the Install stage, removing all terms for any named vocabulary. This will sync all terms when a git pull is done, quite nicely, until... shudder... content is defined that references the terms. Adding code to test for references is one API function call. Easy.
It's been fun coding Drupal 7 objects, which the Taxonomy API uses that. Very easy.
I decided to assign a weight, increasing for each new term, so it's non alphabetical, matching the input. The input is no longer a clumsy array, but an input file, one term per line, with the file name of the vocabulary, stored inside a subfolder of the custom module called 'scale_terms'. The format is hardcoded to 'filtered_html,' as I doubt that will change for these SCALE terms.
I'm sure this scale_term module will be short lived, as it's useful only when first creating the Terms, not after they have references to them. However, I used a subfolder name of "terms.new.no.refs" to hold the input term files, implying the vocabularies found there will have "no references", and it's safe to delete the entire vocabulary before installing the new one. Thus, other folder names can be meaningful, that is control how this module might add the terms.
I'm not sure this is a strong design direction, but it's fun doing my first Drupal 7 module, a highly customized one at that. It's very Features like, manually created though. A snippet of training interest.
I'm not sure when the code will be ready to post. I hope Tuesday night at the next SCALE Barnraising it can be fine tuned for the new CFP requirements.
Pete
Peter
LA's Open Source User Group Advocate - Volunteer at DrupalCamp LA and SCALE