Looking at some recent licensing boo-boos, we came up with a nifty little tool to help you find the right license for your open source software. Any feedback would be appreciated, whether involving data correction or other features / categories you'd like added.

Within just the last several years, concern over climate change has grown significantly.

Interestingly enough, environmentally-focused online user engagement is an idea that remains largely untapped.

For the first time in human history, we are faced with a problem that needs worldwide cooperation to overcome. Scientific studies are showing time and time again that global warming is a very real problem. The effects from this unnatural global acceleration rate are already noticeable, and the media outlets aren't hesitating to scare us as much as possible.

The media, much like the web of the old, broadcasts an impersonal message to a collective whole. It speaks of climate change as if it's an inevitable fate. They speak of this problem as one of tremendous scope, and one that would require more than a goliath effort to undertake. Most people want to make a difference, but are intimidated by the size of the problem, given no direction, and are shown no clear community for which they can participate.

Web2.0 is personal. This "new media" can inspire awe through stories of overcoming obstacles. It can bring about one's inner determination using public disclosure to shock and sicken. It can also simply provide tools to allow users to build their own connections. Interactive media and public disclosure can cause people to want to act, but it's not always enough. Some of us need a personal trainer, not just a nudge. We need to narrow the scope of the problem so we can see exactly what difference we're making at a personal or community level. As this Yahoo CO2 calculator demonstrates, people need to see that even tiny lifestyle changes can make a difference. There needs to be a way of showing progress, a way of clarifying that their "baby steps" are being taken by countless others too -- adding up to an enormous leap forward.

There are some great web projects devoted towards reducing carbon emissions at the individual/community level, but the playing field is still very much open.

While reading some code, I came across a pleasantly surprising snippet that a coworker had added, and it went something like this:

Calling functions through variables

function display_output()

{

    return 'This is the output text!';

}

$variable = 'display_output';

echo $variable();



Result: $variable() = 'This is the output text!';

With closer inspection, this is a pretty cool feature in PHP. It allows you to dynamically call a function by treating a variable like a function. When parentheses are after the variable name, PHP calls the function whose name equals the variable's value. Ex: if $foo = 'bar', then doing $foo() will try calling a function named bar(). Sure, the same result can be achieved using IF loops, but in PHP, it's always good to at least know of the alternatives.

Variable variables

$charlie = 'delta';

$delta = 'oscar';

echo $$charlie;



Result: $$charlie = 'oscar';

My coworker, Oscar, also informed me about "variable variables". These buggers have that extra dollar sign. In the previous example, PHP looks at the value of $charlie, which is 'delta'. It then returns the value of $delta, which is 'oscar'.

Creating variables dynamically

$when = 'future';

$variable_past = 'Welcome to the past';

${'variable_' . $when} = 'Welcome to the ' . $when;



Result: $variable_future is created, and $variable_future = 'Welcome to the future'

This is helpful for when you need to create numerous variables on the fly, such as within a FOR loop. However, it may end up making more sense to create an associative array, depending on how much data you need stored. Ex: $container_array['dynamic_name'] = 'some_value'; Again, this all depends on your given situation.

I mentioned in the previous post that a widget is just some code that people can stick on their website. A web-based widget can be directly embedded (such as a Flash or Flex application), or it could simply be an IFRAME linking to code somewhere else. For this example, I created the file widget-photo.php and linked to it from an iframe.



The cool part of this example isn't that a page "lives" within another. The magic happens when the user searches for their local congressperson. When a last name is submitted, the code within the embedded page makes a couple API calls. Using the SunlightLabs API, the PHP script asks for a list of congresspeople with the given last name. The SunlightLabs API returns a nicely-formatted JSON result set. We have officially used an API.

A mashup is just an easy way of saying that two or more functionalities have been combined in hopes of producing something more interesting / helpful / meaningful / awesome, etc. A pretty solid mashup example is HousingMaps, which mashes together craigslist and Google Maps.

The example isn't over yet. We have just returned data regarding a congressperson or bunch of congresspeople. We're about to display them, but there's something we forgot before making this a true mashup. For each congressperson, we're also making a call to the CARMA API to try and find some other information related to that person. We make a call, enter the congressperson's name for the input, and in exchange are given an XML file of that congressperson and their CARMA statistics. How we choose to display all this information is anyone's call from here.

Mission accomplished.

Source: http://tech.forumone.com/code_examples/widget-photo.phph

In the next several months, we'll be rolling out several widgets that take full advantage of CARMA's Application Programming Interface.

The CARMA website, especially with the Dig Deeper tool, allows the user to sift through vast amounts of cleanly presented CO2 emissions data like never before. Plants, companies and locations can be filtered by numerous criteria, including but not limited to: future power output, present CO2 emissions, past intensity and parent location. Maps present an intuitive display to compliment the raw data.

With all this information in the CARMA database, there's no wonder that some connections were left untouched. We just couldn't add too much information to the website without it getting overwhelming for the casual visitor. If you have unanswered questions after viewing the CARMA site, then the chances are that the API might be worth looking in to.

With the CARMA API, you can create a widget to simply repackage CARMA data. Examples include:
1. Displaying the future emissions of planned power plants by location.
2. Displaying trends in emissions and carbon intensity for specific plants, companies, or geographic regions.
3. Looking up the carbon intensity of power providers by zip code in the U.S.

You can also mashup data from CARMA and other sources:
1. Using the carbon intensity of individual power companies to calculate accurate carbon footprints for individual users.
2. Mashing up CARMA’s emissions data with campaign contribution data for congressional districts.
3. Mashing up CARMA’s power company emissions data with financial information.

Remember that a lot of the plants have coordinates, so creating visually-appealing map widgets (perhaps mashing up with other types of geographic data, like asthma rates) is entirely possible.

A widget is a little chunk of code that people can call their own and place on their blog or website. For example, this widget simply grabs the latest RSS feeds from somewhere. Some other widgets are more interactive, such as for weather, allowing users to enter some inputs (in this case, their zip code).

Calling the API is relatively simple, and it returns data back in XML format. Let's say that you wanted to get the raw data for the state of California. You can simply browse to http://carma.org/api/1.0/searchLocations?name=California. To build a widget, you could make multiple API calls and even mash it up with external data sources (like Yahoo! finance).

We created the API so anyone can download the raw data and use it to form their own connections. Forum One will be creating several widgets to showcase the great potential of the API, but the real excitement comes from how you interpret and display the data.

Dan and I are back from the MySQL for Developers training, and we decided to share the enlightenment. Instead of boring you with a summary of what we've learned, we've decided to divvy up our notes into various "tips & tricks" posts.

Let's say that a client sends you an Access, Excel, or CSV file and tells you to stick all that information into your database. The client is oblivious to the structure of your table, and the file contains several columns that aren't needed. Some of the other columns are improperly formatted, making your life that much harder.



Your first instinct might be to write a PHP (or Perl, or Python, etc) script that squeezes and trims data to the right dimensions, then sends to MySQL. That's fine, but many don't know that MySQL can usually do this tedius work for you. It might also be worth mentioning that MySQL parses this data exceedingly fast.

LOAD DATA INFILE (or LOAD LOCAL DATA INFILE from your local machine) is an importer's dream come true. It allows for MySQL itself to load and parse a file. Once loaded, you can set the FIELDS TERMINATED BY, ENCLOSED BY, LINES TERMINATED BY, and IGNORE ... LINES parameters to split the data into meaningful chunks.

Setup:

LOAD DATE INFILE '[file.ext]' INTO TABLE [table_name]
FIELDS TERMINATED BY '[column_separator]'
ENCLOSED BY '[usually doublequote]'
LINES TERMINATED BY '[usually \r or \n]'
IGNORE [lines_to_skip] LINES
(col1, @variable2, col3, col4)
SET col2 = SOME_FUNCTION(@variable2, some_parameters);

You can use @variables instead of columns for processing. If unneeded file columns exist, then we store that column into a dummy variable (look at @skip below).

The import file uses "Apr 20 1982" for the birthday, but we want it looking like "1982-04-20". Below, we set the @birthday variable equal to the file's birthday column, then SET birthday (the DB column) equal to STR_TO_DATE(@birthday, 'input_format').

Real-world usage:

LOAD DATA INFILE 'import.csv' INTO TABLE people
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 2 LINES
(id, @skip, @fname, @lname, @skip, @birthday)
SET name = CONCAT(@fname, ' ', $lname),
birthday = STR_TO_DATE(@birthday, '%b %e %Y');

NOTE: STR_TO_DATE expects the input date format to be specified. The 2nd parameter contains the curious string '%b %e %Y'. In this example, it's looking for a date formatted like 'Jan 9 2001'. The meaning of those special characters can be found here.

I would highly recommend attending the MySQL training seminars. David Swain, our trainer, was highly competent and had helpful answers and further insight to every question we could throw at him.

There's no question that most people have heard of AJAX by now, or have seen some interesting uses of it. When done right, AJAX dramatically improves the user experience, but using AJAX simply for "style points" can be disastrous:


1. DIV popups (with AJAX-powered content) appearing without the user's consent (Snap Shots)
We've all seen it before. When rolling over text or a hyperlink, a bubble pops up with a screenshot of the prospective site, or sometimes, context-related ads appear. Anything that takes control or surprises the user is evil. I would never wish something so vile for even my worst enemies.

2. Automatically loading more content when the user scrolls down (DZone, Live)
An age old idiom of web and interface design in general is not to break existing functionality. When the user hits the 'End' key, we expect to be sent to the end of the page, for example. Pageless pagination, or Endless Pageless styles of loading more data break every convention that makes the web analogous to physical medium. No longer can you remind yourself, "Oh, that cool widget was on page 3". We use page numbers for a reason, and although these pageless methods are technically interesting and flashy, they do no service to the user aside from a monotonous scroll-wheel workout.

More importantly, AJAX content keeps getting loaded onto the same page. Add a couple hundred items (each with related images and/or embedded media), and your inquisitive user might start wondering why their browser isn't responding.

3. Multi-page forms that don't support the browser's "back" button (PBwiki)
Here we are again, altering the way a user expects the page to behave.

4. Browser incompatibility (mostly IE)
One of the more annoying uses of AJAX is when it doesn't work to begin with. When working with AJAX, I'd say that a good 25% of my time was spent correcting code inoperability among browsers. Thanks to libraries like jQuery, that time has been cut down dramatically. Regardless, if these various browsers simply stuck to the standards instead of being web cowboys, web developers would have a noticeably brighter outlook on life.

Contributors: Mike Shade, Oscar Merida, Sandy Smith

As a web developer, my job depends greatly not only on how efficient the backend code is, but how intuitive the site is for the user. As the web moves further and further from the "monkey see" to "monkey do" mentality, web developers are needing to become more design conscious.

There are some great User Experience and Design teams out there to do the heavy lifting, but it's important to remember that the success of any site ultimately depends on what makes the user, not necessarily the client, happy. Even if the code is beautiful and highly optimized, the user will be gone in seconds unless they find comfort in the site's layout and ease-of-use. There will undoubtedly be the client who is adamant on a site looking or behaving a certain way, which is fine as long as user testing & feedback is provided. Clients don't often like to hear that their ideas "need some work", but having collected data tends to soften the blow.

No user wants to be hassled into disclosing their private information unless there's a really good incentive to do so. Believe it or not, people normally don't wake up, brush their teeth, and say to themselves, "You know what, I'm in the mood to fill in a couple forms to get the day started". If the user's information is needed, then make the process as painless as humanly possible. As this article implies, only require the user to fill in the bare minimum. Once logged in, any remaining fields can be filled in by the user at his or her own convenience.

Just because the visitor happened to browse to your site doesn't mean that you can or should control their viewing experience. The fact of the matter is that if the user grows wary or even the slightest bit impatient from your site, then then they probably won't be coming back. Selecting the "Sign me up for..." checkbox by default could be seen as disrespect towards the user, and many simply don't appreciate it. The key takeaway is that every visitor should feel privileged, and not feel like they're being rushed through the door to meet some quota.

URL: http://codeulate.com/?p=9

With the help of Forum One, the Center for Global Development (CGD) launched a web-based initiative aiming to reduce global carbon emissions. CGD believes that public disclosure is one of the best steps towards solving a problem, and they came into the CO2 front with some pretty heavy artillery. Kevin Ummel and David Wheeler at CGD worked tremendously hard not only to find and sanity-check the emissions data, but to sculpt it in a way that many will undoubtedly find meaninful. The database itself consists of information for 50,000 power plants and over 4,000 power companies. Google maps have been used to add some flesh to the raw data, and a colored icon is attached to every item to further reinforce the numbers.

What's coolest about CARMA is the ability to "dig" through all the data to find stuff that you'd consider meaningful. The Dig Deeper section allows you to drill down to find plants and companies in your area, as well as the most troublesome (or greenest) ones in your region/country/continent/etc.

Users can download the raw data in CSV or XML formats on just about every page, and if that's not thorough enough, there's a full-featured API. With the API, anyone could pull out data and use it for their own website -- perfect for custom widgets. Examples and helpful tips will shortly be added to the API documentation as well.



Even though we knew from the start that this is a really cool initiative, we had no idea that it would make it to the front page of sites like CNN and NPR. On the day after launch (11/15), the first server buckled under the enormous load, causing a bit of chaos. The site was down for a good 20 minutes while Rackspace upgraded to a new server. However, all is well again, and the steps made towards correcting the problem will be on a follow-up post.

Flash is a great tool for a lot of things, but true 3D has historically not been one of them. In the following guide, I'll briefly share what Flash is good at, what it's lacking, and where you might expect to see Flash in the future.

Overview
Adobe Flash is partly responsible for "bringing the web to life". It allows for slick animations, interactive tutorials, and most notably, embedded multimedia.

What it excels at
The Flash Player has 99% penetration. In other words, almost everyone has it installed on their computer. Most streaming video you see on the web nowadays (including YouTube, CNN, and NBC) uses Flash with various highly-compressed video formats embedded within it. Pandora is a Flash internet radio service that adjusts its playlist based on the user's preferences. Multitudes of 2D games and applications also take advantage of Flash, and it can even serve commercial purposes with various data exchange tools.

What do you mean by "true 3D"?
Sometimes, you may come across "3D" in Flash. Most of the time, the 3D you see is pre-rendered in some third-party application (like Maya or 3D Studio Max), and then imported into Flash frame by frame. What is gained in performance is lost -- and then some -- in the usually massive filesize. If you think that most people are willing to wait several minutes for your awesome "3D" to load, think again.

Why aren't we seeing more true 3D?
The answer is simple: Flash doesn't natively support 3D. When Flash was first conceived, the main goal was to create a lightweight framework for web interactivity, NOT for CPU-intensive 3D applications and games. Shockwave was meant as the feature-packed 3D toolset, whereas Flash focused on making the download as small as possible so everyone can get it.

Also, several other features are lacking in Flash that are standard in other 3D-specific platforms:

Crunching power: Complex scenes are very processor-intensive, and Flash is still at the back of the pack in terms of how much data it can handle. If the code isn't sufficiently optimized, an insanely low framerate isn't far-fetched.

Texture mapping: No official support for sticking textures into 3D surfaces currently exists.

Z-plane: Flash doesn't know what this is. Flash uses 2D layers to determine what's nearer and farther, and with 3D objects, it can be quite tricky to realistically show that only part of a 3D object is behind another.

As of recent, a lot of energy has been devoted towards getting more complex 3D to work in Flash.

What efforts are being made?
Although Flash CS3 still doesn't support native 3D, a lot of people are building their own 3D engines. Some of them are actually pretty good, too. Remember that since Flash has abysmal performance compared to other platforms, a lot of attention must be made toward getting as much bang from each coding buck as humanly possible.

Several leading 3D engines include Sandy 3D and Papervision 3D.

The tools for developing compelling 3D visuals and environments are out there. None of them are perfect, because they only lessen some of Flash's fundamental shortcomings. Adobe has undoubtedly taken notice of the increased demand for 3D, and may or may not act on it. In the meantime, it's only a matter of time before people start doing some really cool things with what's available.

In the beginning, there were static web pages.

The geek masses cheered at the ability to put information on the web for everyone to see. More and more web pages were built, and with that, a myriad of useless information also began to pile. Search engines started emerging, with the aim of filtering valuable information from the heaps of useless data.

Then, websites started getting progressively more dynamic. Geeks wanted to jump-start their websites by allowing others to interact and participate. The average Joe wanted to be able to have a web presence and express themselves without needing to know HTML or other coding languages. The raw data kept piling.

Sometime in 2001, Jimmy Wales decided to launch a community emphasizing user contributions of structured, meaningful information. Wikipedia users classify their articles, sanity-check other articles, and relate their article to any other articles. Instead of searching through piles of articles, why not get users to incrementally improve each other's articles?

Every Wikipedia article starts off on the same page, no pun intended. To distinguish between different article types, template code is added into the article. If you wanted to add the current population for the "Roanoke, VA" article, you'd have to manually edit the "InfoBox" tag within the article's wiki source. More importantly, since the data is so loosely structured, there's no easy way to pinpoint other cities with a population similar to that of Roanoke, VA.

When information is ideally structured, much of the burden is taken off the search engine. Freebase aims at cauking Wikipedia's flaw by adding numerous "facets" to the search, as well as keeping the data in concise blocks in the database. Freebase claims to allow for deeper searches than ever possible before. Whereas Wikipedia's data structure is mainly fixed, Freebase has what is called an "Open Contribution Model". This means not only that different content types physically exist (without the META-ness) for different articles, but also that users can CREATE new content types, essentially extending the database structure. This concept of a dynamic database is something that has been virtually untapped until now.

Also, Freebase allows users to upload entire data sets, not just individual articles. Suppose I wanted to create a content type for "Squirrels who survived a rattlesnake attack", I would add fields like "Name, Animal type, Location, and Date". "Animal type" could automatically look-up the squirrel's scientific info from a separate content type, "Location" could either pull up other squirrels bitten at this location or the geographic/demographic details of this location, etc. The possibilities are limitless. Oh yeah, and there's an API and even a Query Editor, too.

To show how unbiased this database structure really is, try out this FilmSpin example. Even though it only uses 2 content types, it sleekly shows how meaningful those relationships can be among varying content types. Freebase is still in alpha, and shows great potential of taking the buzz away from Wikipedia and other sector rivals.