Confessions of a Web Developing Phony
Here is a quick code snippet to put that pretty, pipe-seperated navigation into the bottom of your site, so that Google can eat it all up.
foreach(menu_navigation_links("primary-links", 1) as $m):
$arrNav[] = l($m['title'], $m['href']);
endforeach;
echo implode(" | ", $arrNav);
Substitue “primary-links” for the internal menu name of your choice. Enjoy!
I get asked a lot how to go about adding certain CSS files to only certain pages of a Drupal project, rather than every page. This is commonly desired when you are using a drastically different front page in comparison to your drill pages. To achieve this you will want to use the drupal_add_css() function provided by the Drupal API.
It’s very basic in functionality:
drupal_add_css(path_to_theme() . '/layout-fixed.css', 'theme', 'all');
Given a path to a CSS file, it will load it where ever the function is called. The second param specifies whether you are theming a “theme” or a “module” with it, and the third param reffers to the “media” attribute of the <link> tag.
I’ve seen many coders drop this call right into the page or node template they are theming. That is really less than desired, as it tightly links a css file to template file. Say you wanted to use this css file 5 times, you would have to add it to 5 files. That duplication would make it time-consuming to change if you had to alter the name of the file, for example (and that is provided you can remember where you put every call to drupal_add_css()).
A cleaner approach is to put it’s call in your template.php and use some logic to control when to use it. Something like:
if($_GET['q]=="node/2") {
drupal_add_css(path_to_theme() . '/crazy-style.css', 'theme', 'all');
}
Doing this will ensure that all of your dynamically added CSS’s files live in one spot, making it super easy to add or extend to.
To remove an existing CSS file per page, try something like:
$arrCSS = drupal_add_css();
unset($arrCSS['all']['theme']['path/to/css-file.css']);
$vars['styles'] = drupal_get_css($css);
return $vars;
The web is literally bursting with great ideas and it seems that every day, new web applications are emerging that are offering really awesome functionality to make life easier and fun. Us developers spend large amounts of time coding up these apps, and one of the trickiest parts is always the merchant transactions. Chargify has taken care of all that by offering you access to the most popular merchant gateways, with no transaction fees, only a monthly fees based on volume. Simply sign up for an account based on your volume, create your products and pricing tiers, and hook into their API via your web application – it takes care of the rest! No need to store credit card information, write recurring billing software, etc. Check it out http://chargify.com/
Did you ever have a folder that was nested with .svn folders and you wanted to quickly remove them and just make them a non-versioned folder? Perhaps because you are going through old repo checkouts that are too out of date to care, or you want to copy a repo-ed folder to a new project without it being externalled, or maybe because the folder got screwed up on a commit and you just want to recommit it? Try running this unsvn code.
#!/bin/sh
find . -name ".svn" -exec rm -rf {} \;
Just save this code to a file (I call mine “unsvn”), run it from the parent level directory and it will remove all .svn folders in itself and all of it’s children.
I found this and I just thought it was too adorable not to repost: http://37signals.com/svn/archives/000606.php
As web developers, whether you are a designer or a programmer, you have to manage tons of information to complete your project as quickly as possible, and with all of the requirements of the client in mind. It doesn’t matter if you are a large web shop, or the freelancer starting out with a small number or projects, you need to be organized. Organization of data, feedback, tasks, contact information, assets, and any other requirements ensures that you can maintain the big picture of the project, all bullet points, and that you have a paper trail of where direction and decisions came from.
However, it seems that though every size shop requires the same things, we can’t all seem to settle on the same software to organize our projects. The one-man show doesn’t want to pay $24 a month for a tool that deprives him of time-tracking and is deeply ingrained in multi-user collaborative features. The large company has problems with its oversights: it doesn’t account for maintenance or non-project work items, it doesn’t organize e-mail tickets, it doesn’t incorporate invoicing, and other random nuances that large shops have. Therefore, large shops are forced to have a number of subscriptions to varying SaaS apps, with redundant data, making an uneasy experience for the workers. This is no slight of BaseCamp, the extremely popular software is just one of many who offer powerful tools for managing projects.
I have a vision for software that manages the way your web shop works, and not just how you organize projects. My ultimate goal would be to develop a turn-key application that allows companies large a small to handle the life cycle of a client and their project. We are at an amazing time in web development, where information accessibility and frameworks are turning hobbyist into professionals. Larger shops are at a huge advantage too, with an infrastructure in place, and the business world acknowledging having a web presence like never before, your revenue is only limited by your turnaround times.
That’s why I am calling on you, the reader from all walks of life, to tell me about your day-to-day work process as a web developer, and how you vision an organizational application to handle what you do. Please leave a comment below, and I promise not only to keep the development of this application customer-driven, but to also to give you beta invites (so make sure to include your email address!)
Thanks in advance!
I found this little snippet of code, simply stick it in your address bar and it will create a script element that loads jQuery from Google, so you can use jQuery calls from console.
javascript:void((function(){j=document.createElement("SCRIPT");j.src="http://code.jquery.com/jquery-latest.pack.js";document.getElementsByTagName("HEAD")[0].appendChild(j);})())
Out of the box, Drupal has a really awesome cascading filename theming system. It is really easy to theme idividual content types simply by naming your file “page-contenttype.tpl.php”. But many times, I want to be able to create a bunch of “Page” content types really quickly (ex. “About Us”, “Privacy Policy”, etc) and theme it uniquely by node. Personally, I think it’s easier to be able to name your files according to the title of the node, and not by IDs, because when I come back to a project in a month, I won’t remember what “14” is referring to.
To combat that, I use this little helper hook which I drop into template.php
function theme_preprocess_page(&$vars, $hook) {
if (module_exists('path')) {
$alias = drupal_get_path_alias(str_replace('/edit','',$_GET['q']));
switch($alias) {
case "override":
$vars['template_files'][] = "page-different-filename";
break;
default:
if($alias != $_GET['q']) {
$template_filename = 'page';
foreach (explode('/', $alias) as $path_part) {
$template_filename = $template_filename . '-' . $path_part;
$vars['template_files'][] = $template_filename;
}
}
break;
}
}
}
Now, by default, you can name your page template files by a hyphen-separated list phrase of the node title. So if I make a node called “About Us”, I can now theme the page by creating a template file named “page-about-us.tpl.php”. If you have a case where the default naming convention won’t work for you, simply put a case in the switch statement to case the particular page by slugged title.
As I sit here at O’Hare Airport, eyes burning from the lack of sleep, I’m finally getting to wind down mentally and really absorb exactly what I’ve learned from the 2009 An Event Apart conference in Chicago. As a long time ALA reader, I was absolutely pumped to come out here for the first time and take in some of the cutting edge information straight from the horse’s mouth: a collection of industry heavyweights and unsung heroes alike. Put on by Eric Meyer, of noted CSS fame, and Jeff Zeldman, known for his contributions to web standards, the conferences have firmly established themselves as providing the de facto standard as to the quality and gusto, that certain wow-factor, that our imaginative and creative peers crave when making substantial investments of time and money into our careers.
The conference was split among two days; the collective genre of the speaker’s topics from the first day focused more on the business side of web development, while the second concentrated on code, developments strategies, and concepts to open our minds and tries to nudge the industry forward.
If I had to give the conference an overall grade, it would be a B. It’s a grade that leaves you thinking “I wish it was an A, but I’m glad it wasn’t a C”, and that’s pretty much my reaction. While A List Apart is normally known for introducing new and high-concept topics, the conference seemed to amplify sentiments from the past year. To say I was unsatisfied would be a lie, but to say I was blown away would be one too.
Note: all photos beautifully captured by John Morrison – © 2009 John Morrison – subism studios llc – link
The brain behind Happy Cog, Zeldman gave a talk about ensuring we are solving the problem that we were asked to. He emphasized the importance of research to help fight your case, gain trust in your client, and ensure that you are addressing the task at hand. Don’t forget about tried-and-true software design principals, such as scenarios, to show how the site you are developing will address that research. My favorite section of his lecture was speaking about how to “learn to translate” what the client has been asking for: this is not their native thought process, so we should not assume what they are saying (or complaining about, more appropriately) is really what they want. The culmination of his lecture was to ensure we are addressing “the user, the research, and the problem”. When doing some personal site work, don’t forget that you get bored of your layout way before the rest of the world does.
Final Grade: B – Very solid topic, but played a little too safe for me.
Jason is a guy who leads by example, whether you like his ideas or not. Santa Maria spoke about a point that most will agree with: even though we constantly think about “the big picture”, but realize much of the UX lives within the small details and nuisances that give a site it’s personality. For this reason, his first of three take-aways was to keep a sketchbook, a topic which he wrote about back in April (which was the main reason I started to keep a sketch book on me at all times), so that you are good to go whenever those ideas, big or little, come along. Topic number two was to incorporate a grid system, whether a pre-packaged one like 960, the up-and-coming Blueprint, or rolling your own. In addition, he suggests thinking horizontally as well as vertically; we constantly think about columns, but horizontal content chunks help to maintain consistency even if you vertical layout needs to change ( see Jason’s site, jasonsantamaria.com ). Lastly, point three was his take on how to use fonts, suggesting that you should try to stick with one serif font and one sans-serif font.
Final Grade: C – The sketchpad idea is very important and related well to “thinking small”, but the grid section didn’t seem as relevant, and the font ideas just seemed very opinionated.
An amazing take on what could have been a topic dowsed in buzzword fluff. The head of Brain Traffic, she spoke of how to better integrate content into the life-cycle of the projects, a method BT used to produce a range of satisfied customers from state universities to Target, alike. In addition to site maps and page tables, she suggests using a “content inventory” system to audit a pre-existing site to know exactly what you have out there for visitors to see ( a system which I have already used with a client, only 4 days after she informed me about it). The net result is building a stronger brand, better audience targeting, and more optimized content for search engines.
Final Grade: A – For me, Kristina optimized the level of new and credible knowledge that loyal ALA’ers are accustomed to.
Following in perfect suit, Dan Brown, author of the must-have Communicating Design, introduced “concept models” – a new approach for identifying content relations for a more potent information architecture. Similar to RDB mappings in idea, not only did he introduce the concept, but he walked through procedures of defining and developing the models, the common patterns to look for, and he backed it all up with real world examples.
Final Grade: A – Just like Halvorson: introduce your concept, explain it, show the details, give solid examples. Very direct idea, which was extremely valuable, and instantly usable.
True to her New York roots, Hess spoke about a sort-of guerrilla approach to developing a user experience. She walked us through some cases studies, including how Iridesco, creators of Harvest, hooked up their contact system directly to a G-mail account, and built a back-end feature request system, to build what the users want, and not what the development team thinks they want. Her main take away point was you can upgrade your UX by design research, web analytics, usability testing, and experimentation and iteration.
Final Grade: B – Hess not only helped dissect UX into very graspable components, but also gave the common man techniques to implement on their projects now.
What isn’t there to say about this upstanding gentleman? After suggesting that he was a secret agent in a past job, I then went on to listen to his lecture about “tearing down the walls” by designing in the browser. As a developer who masquerades himself as a designer, I am all for designing a site in the browser; after all, it is the medium we are addressing – the main selling point of Clarke’s lecture. Designing in the browser allows for more interactive mock-up reviews (rollovers, mouse* events, etc), faster edits to fonts, and it addresses browser anomaly issues up front, rather than after a client approves a lifeless mock-up. The technique is also extremely powerful for rolling out multiple template mock ups in a faster manner, as examplified in a case study for the New Internationalist (note: as of 10/19/2009, his design isn’t implemented).
Final Grade: B – I applaud Andy’s efforts on presenting a topic that antagonizes the recent photoshop-fluff site mantra that has emerged over the recent years, but find that his technique only stands for a certain category of clients that do not desire a “pixel-perfect” design. While I wish we would openly adopt his design technique, it’s going to be a while until we get there.
Meyer’s talk, “JavaScript Will Save Us All” was pretty much a recap of all the cool things that JavaScript can do for us, now that the engines have been getting much more powerful. He went on to talk about how JS is being used to level the playing field so Internet Explorer can hang with the big-boy browsers with scripts such as IE7-js, how it is the driving technology in tandem with flash for font substitution schemes such as sIFR, and a handful of other creative uses like interpreters and CSS extenders and the like.
Final Grade: C – To quote a tweet I posted immediately following his lecture “Am I the only one who feels like they were expecting more from this topic? Everyone seems kind of pumped …I kinda feel like ‘and…’”. I am a huge fan of Meyer, but a recap on the products of a technology that most professionals are already familiar with and use everyday is not what I was expecting from the industry giant.
Aaron presented eCSStender (pronounced “extender”), a JavaScript utility that allows all browser to implement properties that are not currently supported consistently, as well as creating your own brand of toolkit, in which you can create your own CSS properties. The script implements a hook system, in which unsupported properties turn to eCSStender to find a JavaScript function to fall back to. Written framework-agnostic, Gustafson showed very detailed examples of the features eCSStender has to offer, and how to implement in a couple of real world scenarios.
Final Grade: A – While conceptually I’m not on board with the idea, you have to applaud Aaron’s efforts at crafting a product that is not only a solution to browser anomolies, but also extends the capabilities with JavaScript. A unique idea, definitely in the ALA league.
Simon wrote about “building stuff fast and getting it approved”: his lecture outlined ways to develop products faster using new, agile-esk techniques. A core creator of Django, the python web framework, he mentioned the ability to utilize tools in your given development language to prototype faster: Firebug for CSS/JS, IRB for Ruby, BeanShell for Java, etc. He then spoke about the ability to use JSON with padding (JSONP) to quickly build apps using APIs from other sites. Additionally, he talked about YQL, Yahoo!’s content query system, “/dev/fort”, which was he and a group of his peers locking themselves in a fort in England to conceive, design, and develop a site from start to finish, hack days, screen scraping, open source, and git hub.
Final Grade: C – If you haven’t already gathered, his lecture was incoherent and erratic. Willison definitely seems like a guy with a lot of great insight, but he needs to really work on tightening it up to an obtainable stream of conscience.
An in depth evaluation of the psychology of forms, brought to you by the man who, literary, wrote the book on the topic. Luke took us through very well known examples of web forms, including PayPal, Amazon, and LinkedIn, to illustrate common pitfalls with form design. He presented us with findings of his research into how users respond to forms with vertical label alignments (better for ease of use) versus horizontal label alignment (better for updating). He used heat maps to display how visitors navigated through certain forms, gave a detailed analysis of how to use client side validation, and whimsically took us on a “who’s who” of screwed up web forms.
Final Grade: A – I may go out on a limb and say that this was my favorite lecture. Definite ALA material, Luke presented forms in a way I’ve never heard before. Also, he definately walked away with the quote of the event, “This is the web … fix it”
Rubin’s lecture on “Designing Virtual Realism” was a walk-through on the world of interface design, and how it relates to the web. His big takeaway point was that great design explains itself, and that a natural feeling interface will create the illusion that an application actually performs better.
Final Grade: C – Reminiscent of Simon Willison’s “buck shot” approach to lectures, it was sort of hard to follow. Half way through, his speech turned from creating realism to adding textures to your background. When it was all over, I’d be lying if I said I felt like I learned something.
Wrapping up the event was a very hands-on approach to demonstrating the power of CSS3, combined with that tactful approach of progressive enrichment. Through the use of his very elegant demo site, dowebsitesneedtobeexperiencedexactlythesameineverybrowser.com, Dan shows us how we can add little hints of new CSS properties, even though not all browsers will render these styles the same across the browser spectrum, by utilizing eight techniques, one of which is to start using RGBA.
Final Grade: B – Dan confidently walked us through a barrage of new CSS techniques, and alluded to a bunch of great techniques that I have no doubt we will start to see emerging as trends in the upcoming years.
There have been many debates back and forth between the development communities as to how your URLs should look. 99% of the time, you are going to find that it is fueled by whatever Mr. Google says to do. That is just fine for ramping up your SEO results, but what about for your applications?
While I am not about to offer any new discipline or technique that you haven’t already heard before, I may offer way for you to approach a very common URL technique that is new to you. The good folks over at the Symfony Project offer, what I feel, to be a very logical method of creating the routes to your web application.
How many times have you seen a url like this …
http://www.example.com/user/432
…and how many times have you tried to change that number to look up a different user?
That is the theory behind using your address bar like a command line. There is no harm in guessing what value should be in there. We build URLs intuitively, and they should be used intuitively. Most people from the Linux community will agree, if we don’t have to use our mouse, we won’t. So if I see I can see how an application is creating it’s URLs, I will use this to my advantage, and it’s foolish to think that your visitors won’t if they are a little tech-savvy.
Take a look at this quote from a tutorial directly from Symfony:
In a web context, a URL is the unique identifier of a web resource. When you go to a URL, you ask the browser to fetch a resource identified by that URL. So, as the URL is the interface between the website and the user, it must convey some meaningful information about the resource it references. But “traditional” URLs do not really describe the resource, they expose the internal structure of the application. The user does not care that your website is developed with the PHP language or that the job has a certain identifier in the database. Exposing the internal workings of your application is also quite bad as far as security is concerned: What if the user tries to guess the URL for resources he does not have access to? Sure, the developer must secure them the proper way, but you’d better hide sensitive information
Couldn’t agree more.
There is no magic potion here, so this will be more of a resource for people looking to learn by example.
Let’s say your application is for movie theaters, and has one functionality of fetching a theater listing by state. A logic approach would be to build your URLs as example.com/theater-list/[state abbreviation]. So if I live close to the border of New Jersey and New York (completely hypothetical, of couse) I can look up example.com/theater-list/nj to find all of the theaters in New Jersey. Then, when I decided I’d rather go to the Imax theather in New York, I can switch it to example.com/theater-list/ny . Sure there is a link on the page to select New York, but typing is just that much quicker –and that means improvements in “click”-thru’s.
Step one involves creating an httpd.conf (or .htaccess) directive to force any request to be routed to index.php.
1 2 3 4 5 | RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] |
Now when you try to fetch example.com/theater-list/nj, it will still load index.php, but you can parse out th request URI to call an apporiate file and load specific data.
Request URI = theater-list/nj
$Page_Identifier = theater-list (maybe use it in a switch … and let’s say, call theater-list.php)
$Data_Identifier = nj
So now inside of index.php
1 | require_once ($page_indentifier); // which is a file that we indentified using "theater-list" |
Then, inside of theater-list.php, do something like
1 | $sql = "SELECT * FROM theater-list WHERE state = '". $Data_Identifier . "' // of course, you will cleanse this data |