OpenSourcery Blogs

Last Friday I met Aaron and drewish at the Ace hotel for a day of SimpleTest writing for the long-awaited hook_file() patch. This was part of the Portland Media/Files Code Sprint, organized by drewish to solidify the patch during the week of OSCON.

The day was very productive, as file.inc went from having virtually no tests, to near complete test coverage. As is often the case when writing comprehensive unit tests, several inconsistencies with expected behavior/documentation were found and fixed.

Aaron has provided an overview of the goals of the code sprint, and the remaining work to be done (both on the immediate patch, and beyond). But to summarize, the goal is better file (thus, media) handling in core.

If you maintain or develop modules (or themes) in Drupal that need to deal with any sort of files, go give this patch a try (it's currently the spotlight patch).

I've had a tremendous amount of fun writing tests for file.inc (hopefully I'll get to do a few more before the patch goes in), so I may very soon jump on some of the other needed tests for Drupal core.

Oregon Public Broadcasting just broadcasted a radio show on OSCON, open sourceOpen source software is computer software for which the human-readable source code is made available under a copyright license (or arrangement such as the public domain) that meets the Open Source Definition. and Portland. Where does Portland fit in the global open source economy?

listen in here:

http://action.publicbroadcasting.net/opb/posts/list/1356610.page

We at OpenSourcery are frequent visitors to Rick Turoczy's informative, funny Siliconflorist blog, but with all the great events and companies in Portland we sometimes feel left out.

So we were excited to find ourselves jumping out from the virtual page this week in connection with BeerForge III. All we must do, it seems, is host a huge party with free booze and 500 person capacity for the accolades to start rolling in.

Check it out: http://siliconflorist.com/2008/07/24/oscon-2008-beerforge-iii/

As you'll read elsewhere, BeerForge was a great success. So great, in fact, that I sit here nursing my own hangover and ripping through the gum/mints/antacid from the hangover kits we provided to partygoers. And so ends this addled posting.

A common scenario we encounter is where the bulk of a site's traffic is anonymous users, for whom it would be an unnecessary burden on the server to transfer pages with SSL. However, it is still desirable to serve some parts of the site with SSL (typically the admin pages, or perhaps some commerce-related pages). Luckily, the securepages module accomplishes this nicely.

This approach has a drawback, however. The same session cookie is used to access both SSL and non-SSL pages. Since this cookie is passed around in plaintext, it's easily hijacked by an attacker, who can then access your SSL-protected pages with the hijacked session.

While working on a CiviCRMCiviCRM is an open source and freely downloadable constituent relationship management solution. CiviCRM is web-based, open source, internationalized, and designed specifically to meet the needs of advocacy, non-profit and non-governmental groups. site, I ran into a problem of migrating the installation from the development host to the QA, and from there to production. Since CiviCRM stores so much host-specific information in the database, every transfer needed to re-configure the host information. After much research and a little bit of pain, we discovered that the proper way to do this is to simply empty the config_backend field in the civicrm_domain table.

So with this little bit of code tacked onto our deployment scripts:

#Reconfigure the CiviCRM backend
echo 'UPDATE civicrm_domain SET config_backend = NULL WHERE id = 1;' \
| ssh $USER@$HOST "mysql -h $DB_HOST -u $DB_USER -p$DB_PASSWORD $DB_NAME2"

deployments are once again flowing smoothly.

While working on importing a bunch of content from an old Drupal site to a new one, I discovered a little gotcha with the D6 database schema functionality. The method I was using involved loading a bunch of nodes from the old database via a call to db_set_active(), followed by a series of calls to node_load(). Once I had the nodes in an array, I switch to the new db via another call to db_set_active and store the nodes via node_save().

The problem arose due to the fact that Drupal is caching database schema information. Thus, during the node load phase, CCK attempts to load up information on a table that doesn't exist, and the result is cached. When back in the new database, where the table really does exist, the cached schema thinks it doesn't.

The solution was to clear the database schema cache every time I switched back to a different database:

function import_old_set_db($db = 'default') {
  db_set_active($db);
 
  // clear schema
  drupal_get_schema(NULL, TRUE);
}

The key in the above function, which I used as a wrapper to db_set_active() in my import script, is the call to the drupal_get_schema() function, which clears the cached database schema information.

This was a viable solution because this is a one-time import script where performance really isn't an issue. It would not be recommended for production sites when regularly switching between databases during normal page loads.

I ran into the following issue while developing a bilingual (English and Spanish) site recently:

I wanted the site, for ease of use, to have a single menu structure so translators didn't have to worry about mimicking the primary navigation every time they translated a page or added a new one.

The problems, when the site was in Spanish, were three-fold:

1. Primary links were linking to es/english-path even though es/spanish-path existed.
2. For every sub item that was in English, when on the translated page, the secondary menu didn't display, since the menu system didn't see the translated page as a child of the parent.
3. Both primary and secondary link text was still in English.

The 3 issues were solved as follows.

in theme_preprocess_page:

  $vars['primary_links']   = _opensourcery_primary_links($vars['primary_links']);
  $vars['secondary_links'] = _opensourcery_secondary_links($vars['secondary_links']);

and these 2 functions look like this:

function _opensourcery_primary_links($primary) {
  global $language;
 
  foreach ($primary as $lid => $link) {
    $link = opensourcery_translate_translate_path($link);
    $primary[$lid] = $link;
  }
  return $primary;
}
 
function _opensourcery_secondary_links($secondary) {
  global $language;
 
  // This function call will rebuild the secondary menu as if the page were in
  // English, thus solving the second issue.
  if ($language->language == 'es') {
    $secondary = _opensourcery_rebuild_secondary_links();
  }
 
  foreach ($secondary as $lid => $link) {
    $link = opensourcery_translate_translate_path($link);
    $primary[$lid] = $link;
  }
  return $secondary;
}

As you can see, the key to each of these functions is the opensourcery_translate_translate_path($link) function, which looks like this:

The Session Favorites module provides a "Favorites" or bookmark system based solely on a browser cookie. This allows site visitors to aggregate lists of content without becoming full-fledged users.

The module can be configured on a per-node-type basis, and optionally provides AJAX add/remove links.

This module will soon work alongside the Favorite Nodes module, or possibly Views Bookmark (or both, depending on demand), such that once a visitor registers or logs in, their collected session favorites are transferred to the more permanent Favorite Nodes or Views Bookmark storage.

We're frequently asked how we get a web site to return well in search engines. Well, there's really three basic ways to optimize this:

1. Pay for it. Yes, you can get better search engine results by throwing money at Google. It's called Google Adwords - https://adwords.google.com
2. Build a site with the information your audience is looking for. Does your site have the relevant information your site visitors are looking for? Does it go into more depth than other sites? Is it better quality information than other sites? If not, they why would you expect to be more popular than the competition?
3. Make sure the technical aspects of the pages are tuned well. There are some fairly straightforward guidelines on how to construct web pages so that the seach engines can "read" your text and return your pages when searchers are looking for your keywords. That's what this blog post is about.

If you're a web developer you probably already know most of these tricks. If you do only a little coding it's good to have this handy to guide your work. If you're just a customer wondering what search engine appropriate code looks like, the cheat sheet has good examples. In fact, in any browser you can do a "view source" and see what your HTML tags look like.

Most sites can get their search engine results improved by using a copy writer. Why? Well, for one thing your message needs to be focused on what visitors are looking for. That means writing for your audience, but it also means knowing how to craft the messages that go into the unseen tags that the search engines read.

The Web Developer's SEO Cheat Sheet by Danny Dover

Hello, Everyone!

I was delighted to find presentation slides (in Open Document format) posted to the LinusFest Northwest's home page!

Whilst writing the Video Upload module, I came across Drupal's hook_requirements() function. As it turns out, this is the perfect place to check for all the little stuff your module requires in order to function properly.

For example, the video upload module won't work at all unless it has a YouTube developer key, a username and a password configured.

Check out the website of our friends at Silicon Forest for the latest Portland technology news. The good people at Pronotos, the first social network for scholars, guest blogged to show their gratitude for all their positive experiences in Portland.

Specifically, Pronotos thanked Brian Jamison and the OpenSourcery software engineering team for getting their website up "in rapid fashion."

Find that entry and other informative posts as: www.siliconflorist.com

The Video Upload module, while in alpha state, provides a CCK field type that allows for the end user to upload video directly to YouTube, using a single account for the site.

The video never hits the Drupal host, saving on storage and bandwidth bottlenecks, and the end-user doesn't need a YouTube account, since all video is stored under the site's account. Video can be organized on YouTube with customized developer tags, currently with limited token support.

The module uses the Zend GData client library for communication with YouTube. This can be downloaded here. See Video Upload's INSTALL.txt for details on installing this library.

The module in extreme alpha state, with nightly builds available here.

I found an overwhelmingly positive response from Innotech attendees to OpenSourcery's offerings. The booth-goers had a way of 'juicing' me up as we started talking about OpenSourcery's products and services. I had more fun that I should get paid for; I'd like to see us have Innotechs held quarterly!

People would kind of peer over curiously at the little computer set on our booth's table. "He's about a hundred bucks," I'd say. Amazingly, people became even more interested; it as if the clouds of skepticism had parted just enough to bring warm, golden light that is 'open' and 'value.'

I thank goodness for my engineering background--it was so much fun translating folks' IT needs into solutions; I'd draw up quick network diagrams on whatever was handy--in one case I used a spare napkin!

For the executive crowd, I know from experience that they've generally not time for detailed technical drawings or drawn-out explanations. "I'm going to air-drop an IT solution customized to your needs. I'm going to provide you something that works," I would tell them with no shortage of confidence and know how to back my claim.

On the software side I heard one CTO say, "There's a real need for outsourcing advanced web development work away from the internal engineering staff," one attendee said, "the operations staff are certainly bright but they're not always equipped to build out quality custom content."

Exactly. I could see before a hesitation for outsourcing development under the proprietary model. We're different--we hand you the keys, we give you the source code! I must say that more often than not, a business paying ramp-up costs for internal software development just doesn't make for a lot of value.

Lovdbyless is the first open sourceOpen source software is computer software for which the human-readable source code is made available under a copyright license (or arrangement such as the public domain) that meets the Open Source Definition. social networking platform that has come out for RubyRuby is a dynamic, reflective, general purpose object-oriented programming language that combines syntax inspired by Perl with Smalltalk-like features. Ruby originated in Japan during the mid-1990s and was initially developed and designed by Yukihiro "Matz" Matsumoto. on Rails. The platform has the following functionality right out of the box:

• User registration and logins
• Private messaging
• Blogs
• Photo galleries
• Profiles
• Searching

By building your application on top of Lovdbyless you don't have to worry about "basic" functionality and can spend all of your money creating features that differentiate you from the competition.

Check it out at: http://www.lovdbyless.com/

For those of you out there who've heard about this thin client, $100 student workstation and want to know more, here's a terrific article that explains how it works in fairly simple language.

The introduction:

"You walk into the room. It’s cool and quiet. You see thirty new workstations giving great service. Your cost of hardware was CAD$350 for each workstation, CAD$10 to connect it to an existing 100Mbps LAN, and about CAD$60 for a share of a server in another room (CAD$1 = US$0.87). Your software costs were only some download and CD burn time and forty minutes for installation. Your operating costs are virtually nil. The server runs for months without a reboot. The workstations have nothing but network boot loaders. You back up only one machine, the server. The workstations use twenty watts each and have no fans. Magical? Yes. Magic? No. Arthur C. Clarke once made the comment that “technology sufficiently advanced is indistinguishable from magic”. A stock server or a custom-built server made from off-the-shelf parts has taken the place of the mainframe in a client/server arrangement. Moore’s Law makes the hardware cheap. GNU/Linux makes it free to use to its potential. This is old but capable technology made easy to install thanks to the GNU/Linux revolution."

To read more: http://www.freesoftwaremagazine.com/articles/linux_terminal_server

Thin clients are something we're doing for our clients. Call us today to get started on yours!

We had a great time showing off our thin clients to the Education sector. I was excited to see the educators show a real interest in the product the Sys team worked so hard on; from lab to real--world. We're scheduled to give live demonstrations in the coming weeks!

Just for fun (it's Friday afternoon) here's an image depicting some usefull information derived from your digital camera, your GPS, and a handy script:

The image above depicts exactly where you took each image with your digital camera. My script reads through each of the image timestams, organizes them, and calls another script that goes out to a GIS server (USGS in this case) and automatically pulls down the image's GIS coordinates. The script then labels each image (represented as a number) to coincide with where the photo was taken.

Hello to everyone we met at OETC's Instructional Technology Strategies Conference. It was great fun showing off our $100 student computer (a.k.a. "Thin Client").

Some of you expressed interest in the Thin Client presentation slides. Those can be found here:

• http://www.slideshare.net/BrianJamison

We also had requests for the URL for the company that makes the thin client machines we use:

• http://wdlsystems.com/ebox/ebox.shtml

Thanks to everyone who stopped by to talk to us, and see you next year!

-- Steve Peters, sbp@opensourcery.com 

My dream for thin client computing is finally coming to fruition. Three conditions must be met, in my opinion, for successful thin client deployments. New hardware with lower costs now bring TC's to the forefront as a practical and reliable solution for IT. I'm seeing the "new" paradym take place; it's like looking over a mountainous landscape who's early morning sun lights the valley below.

If you're not familiar with thin client technology, here's a primer.

The three joining technologies for making thin clients cost-effective and practical for general purpose use are:

• Inexpensive Hardware
• Fast/Inexpensive Networking
• Web Based Applications

Traditionally the greatest argument against thin client technologies is always related to the cost of the server and the networking equipment. "Why should I install an expensive server and networking equipment when I can just put a PC on people's desk and be done with it," people will ask, "I have to buy the PC's anyway, so why should I create expense with the rest?"

OpenSourcery staff will soon be blogging about the open sourceOpen source software is computer software for which the human-readable source code is made available under a copyright license (or arrangement such as the public domain) that meets the Open Source Definition. tools we use and develop. Please check back soon to learn more!