PostRank hosting HackWaterloo on April 9th!
HackDays are gatherings that bring together the brightest geeks in technology across Canada. The concept is simple: one day, a co-working space, a collection of API’s from local startups and a bunch of bright minds creating a dozen different apps based on those API’s
via We’re hosting HackWaterloo on April 9th! | PostRank Blog.
A better way to CMS with RapidWeaver
There are some tools that come along and everyone just sighs, “How did we ever get along without this?”
Stacks from [YourHead Software](http://www.yourhead.com/ “YourHead Software”) is one of those tools that made RapidWeaver more complete then we ever knew it needed to be. What makes Stacks so amazing is that it *is* what ever it *needs* to be to *whoever* needs it. So far it’s been a power layout tool of endless shapes and sizes, an ExtraContent device, and RSS scraper, a Twitter badge, a media player… and now, thanks to Joe Workman, a CMS.
A Content Management System (CMS) allows clients to edit their content after their web design/development staff has published the site. So far there have been only a handful of attempts to bring CMS to the RapidWeaver platform; WebYep and PlusKit’s @gdoc(()) implementation. The former requires site licensing and the latter rely’s on Google ever changing Google Docs API.
Now there is a [CushyCMS](http://www.cushycms.com/ “Free and simple CMS » CushyCMS”)(free) implementation built into a Stacks Library item (or Stacks plugin) available from [Joe Workman](http://www.joeworkman.net/products/ “Joe Workman | CushyCMS Stacks Plug-in for Rapidweaver”). By simple dragging a CushyCMS stack onto your stacks page, anything you drop into that CushyCMS stack will be editable on the client side.
Brilliant!
[tags]CushyCMS, Stacks, YourHead Software, RapidWeaver[/tags]
Control your processors in Mac OS X 10.5
Remarkably after nearly one month I am still trying to tweak my system just so. I think this is one of the last things though, my processor preference pane. By default, the CPU controls in Mac OS X 10.5 and not enabled and in fact, can’t be enabled unless you have the developer tools installed.
I like to be able to turn off some of my processors when I am just doing day to day web design and theme development. It’s a good way to save some energy (it’s good to be green) and to be totally honest, coding in HTML, CSS, PHP, Javascript and XML isn’t all that processor intensive. With the developer tool installed you can do this. There two things you can do, you can run the CPUPalette.app and/or you can install processor preference pane.
The CPUPalette.app can be found in `/Library/Application Support/HWPrefs/`. It’s a simple app that doesn’t allow much other than turning the processors on or off. If you click the little pill button in the top right-hand corner you can see a couple of basic preferences for window type, sampling rates and information display. It’s a quick and easy way to both monitor how your cores are being taxed and whether or not you can afford to shut a few of them down.
Your other option, if you you are already familiar with your processor usage, is to install the processor preference pane. Go to `/Developer/Extras/PreferencePanes` and find `Processor.prefPane`. Double click to install it. Once installed I highly suggest you click the “Show control in menu bar” for quick access. You’ll notice by installing the processor preference pane you get access to the CPUPalette.app without having to dig for it.
I Give Apples New Safari 4 Beta a Spin
Apple announced today the launch of their [Safari 4 beta program](http://www.apple.com/safari/ “Apple – Safari – Introducing Safari 4 – See the web in a whole new way”) that claims to lead the way with innovation. I had to test this claim so I immediately downloaded it and gave it a spin. Here are my findings:
* On initial launch you are presented with the “Top Sites” window in which it appears that Safari scours your history for the most frequently visited sites in your recent cache and then throws up their thumbnails in a Core Animation like black gallery for you to pick from. Selecting the edit button allows you to remove items and make others sticky. I presume you can also add others that might actually be more indicative of your “Top Sites”. Again, in true Apple form, Apple seems to be hinging the success of a product on visual wow factor, but admittedly I could see myself making use of this.
* My next reaction was when I created a new tab and found that, a la Google Chrome, the tabs are on top. Why? While I will most certainly get used to it, what is the actual reason for this? I can’t find and difference in their functionality apart from the fact that you can only drag them about from their corner. Aside from that you can still drag them, move them from window to window, create a new window with each tab… there is one option I hadn’t noticed in previous version, “Add bookmark for these X tabs”. Is that new?
* Coverflow in Safari… there have been a few plugins to address this in the past. I guess they are history now. Do I need Cover Flow in Safari? I don’t need it iTunes or Finder so I probably won’t use it here either. But that said, it must be a popular enough technology if they keep throwing it in to their software.
* History search. Now *that* I like! I have always found searching the the history in the bookmarks folder to be painful and unproductive. This history search is insanely fast and (in Cover Flow form) even shows you screen shots of the sites that match your search terms.
* It claims to be faster, using the Nitro Engine. It could be but browsers and web technology today is getting so fast I would be hard pressed to notice the difference. It does seem to be faster overall but am I reacting to the guts of a finely tuned OS X Cocoa application or the page load? One note I will make about making browsers faster (and Safari 3 is already guilty of this), they cache things… unnaturally so which can make web development a nightmare. Safari 3 already caches it’s javascript and images in ways that cause web developers to have to reset their browsers all too often just to get an accurate response on their new projects. And faster also means pre-load, again which Safari 3 is bad for. Safari 3 will scour your main CSS file in search of things to load (like background images), whether or not that _thing_ is actually needed or even being used. I hope Safari 4 handles this a little better.
* The newish developer tools are nice (if your weren’t already playing with them in webkit), but I don’t know… it’s still not FireBug. You still can’t select code in the element window! How good is debuggin if I can’t edit what’s there or even copy and past it to a text editor? Seriously? As far as developer tools, these will give a glimpse into how your page is working, but they’re not much good for anything else.
* The full page zoom could be useful (hopefully not for a few years for me yet), but wow does it ever slow things down. Zoom in once and try page scrolling… not so fast now.
* I love, love, love the new address bar! If I am going to interface with browser in any way, it’s through the address bar so this improvement is quite welcome. Basically when you start typing in the address bar you are presented with much the same information your were before, but it’s clearly defined in two categories; history and bookmarks. In both cases it presents you with the site title followed by the URL which makes it very easy to get your bearings.
* The search field is now really slick too. It’s along the lines of Inquisitor, offering you suggestions and previous search queries. Very nice!
* CSS Animation, CSS Effects, CSS 3 Web Fonts… just more things to tease us web developers with. Stuff we won’t be able to use in the real world until all other browsers catch up. We can always dream though…
Overall, I think this is two things combined; a promising look at where web browsers should be and a sobering reminder of how much waiting for other browsers to get there will suck.
nutMac meets seyDoggy
It’s one of the oldest pieces of web real estate I own that still saw some moderate action about once a month or more. But the time has come to close up nutMac and move on. I was writing some more web development tips there then I was Mac productivity tips and either way, I honestly think that stuff is better suited anyhow. So with a little WordPress magic, we pulled in *this* blog from blogger and pulled in the [nutMac blog](http://nutmac.com/) from WordPress, mashed them together and voila! Nothing lost, everything gained.
Now everything we want to write about web design/development, Mac, app review, RapidWeaver development, productivity tips, IE hacking… it’s all here now, in one place, not two. Sounds good to me.
Working with PHP, PEAR and MAMP
So I am starting to play around with [PEAR](http://pear.php.net “The PHP Extension and Application Repository”) in my PHP development and since I use [MAMP](http://www.mamp.info/ “living-e AG: MAMP – Mac – Apache – MySQL – PHP”) I thought I better brush up on getting these extensions to load via the command line like they show for each extension. Knowing that MAMP works things a little differently than what’s already on my Mac I knew that there would be some trick to getting this to work. A quick Google search brought me to [this article](http://www.gringod.com/2007/02/27/using-mamp-on-a-mac/ “GrinGod [dot] Com » Using MAMP on a Mac”) which taught me just what I needed. Sweet!
Use RapidWeaver's %pathto()% syntax in javascript files
UPDATE (2009-07-17): We have updated the code to account for those who were having trouble understanding the reg-ex nature of rTrim. The new code and instructions should make it harder to mess up your path.
It may take me a while sometimes, but there is one simple truth about my workflow, I always strive to have the most efficient way of getting things done. This is especially true in RapidWeaver theme development. Developing themes for RapidWeaver is not like standard web design. You have no way of knowing how each user will structure their site, what plugins they’ll use, what they’ll add to their pages… All of these uncertanties leave us as developers scratching our heads sometimes, trying to sort out ways of dynamically including things and stuff without the end user being able to break it.
PHP would be the obvious choice here, but we don’t have the luxury of knowing what the end users hosting environment will be and whether they could, or even would be willing to support a host of PHP functions. So the next best thing is javascript; yes it’s a little slower and it does depending on the end user having javascript enabled, but the ubiquity of javascript has never been as great as it is today.
One thing that has plagued RapidWeaver developers for some time is how to utilize RapidWeaver’s %pathto()% syntax, the bit of code that allows RapidWeaver to imprint the end users chosen common file path, in any other file other than the index.html template file. For any javascript file that has required the inclusion of another file, we’ve previously had to fill our html with scripted variables for each file, each using the %pathto()% syntax and so forth until we have built a separate path to each file from outside our javascript that actually requires it. Since RapidWeaver will only write the path to files it can actually find, you need to do this for each and every file.
Today I had an AH-HA moment while in need of multiple paths to be defined for use in various javascript files. I decide to write a small bit of code that grabs RapidWeaver’s %pathto()% syntax while it chases a real file. Then I strip out the actual file name, and KABLOW! you have a common file path in the the form of a javascript variable, ready to be used in any javascript file you like.
To be Strict or not to be
I am about to geek out so bad it will make your eyes roll back and have you snoring before you finish the first paragraph. But to be honest, it’s not for you that I write this stuff, it’s for posterity and so that I can always look it up in the future, if such a thing should ever happen to me again.
I have finally nailed down an obscure little bug in cataLog (and in turn Acumen) that was causing the second level navigation to jump up about 14 or so pixels when the user used the “Tidy” setting in RapidWeaver and when the user used code or content that tripped the “Tidy” setting into converting the document into a Transitional DOCTYPE. The reason the bug remained so illusive is that this set of circumstances was not immediately clear and is not necessarily something the end user is mindful of.
My repeated testing, assuming that there had to be a difference in the content area or navigation area, kept leading me down the wrong path. One assumes, when “Tidy” is at work, that the HTML of the document is somehow being altered or “tidied up” as it were. And this is where I continued to search extensively but came up empty handed every time. Having exhausted nearly all HTML avenues and having run countless DIFF comparisons I finally turned my attention on the one thing in each document that I knew was different; the DOCTYPE. By simply switching the DOCTYPE from Strict to Transitional, regardless of whether the embodied code was in fact one or the other, I could trigger this odd navigational occurrence.
As much as this was a major breakthrough in the tracking of this bug, I now knew that the game had gotten that much more complex. I was no longer dealing with a bug in my code or the theme as a whole. I was now dealing with what was potentially a rendering bug, or interpretational difference in the two DOCTYPE’s, meaning that the bug being presented may very well be an issue in the HTML standard itself. Eeek!
Since I knew that the navigation in question uses inline-block as a value on its display property, and since I am well aware of the lack of widespread support that inline-block has among browsers, I knew that this was probably the place to look. I need to look in the CSS of the second level navigation.
Through considerable trial and error I found that an attempt to display the ancestor, or hidden navigation inline was what was causing the trouble. In DOCTYPE Strict, the combination of ul {display: inline;} and ul ul {dispay:inline-block;} caused the initial ul to have height, despite having tried to suppress it with ul {height:0; margin:0; padding:0;} etc… While in DOCTYPE Transitional, the initial ul rendered correctly (which is to say it didn’t render at all and had no height), so the latter ul would shift up to takes it’s position. The fix was simply this: ul {margin:0; padding:0;} with no attempt at any display value other that what it would naturally inherit (which would be “block”).
So is this in actual fact a bug in the Strict DOCTYPE standard? It’s hard to say really. In the making of RapidWeaver themes, we pour a lot of effort and trickery into making things happen the way we want them too. In the case of split navigation we use the same set of code in multiple locations and simply turn on or off the bits we want shown or hidden. This probably is not a typical practice in web design but a necessity in RapidWeaver theme development. Still, why would one DOCTYPE behave differently from another where such a small property in concerned?
seyDoggy is back in the office.
We are back from or little vacay, and back on the horse, if you will, working through a pile of emails and such. On our agenda this week is to address a few bug issues in some of our RapidWeaver themes, namely a footer issue in wideNas, and a couple of mystery bugs that occasionally rear their head in cataLog and Acumen. We should have all of these addressed this week with their respective update installers ready for download.
And as always we are ever moving forward and onward with the theme developments and ideas. We have quite a list of them to get through over the next year or so so you can be sure to see one or two new themes from us every month. Yes that is an ambitious plan, but this is what we do after all, we might very well be the only full time RapidWeaver theme developers now who do nothing else.
And speaking of RapidWeaver, did you notice that RapidWeaver 4.2 has been released? Yes indeed. I have not yet tried it myself, but I have downloaded it and will be getting into it shortly. Learn more about it’s release here.
My top 5 web development tools
As a small web design outfit in Kitchener I have to be particular about my development workflow and the tools I use. I can’t afford to continually invest in new wonder apps that do a bit of this and a bit of that, and do this thing well but not that thing, but this other app does that thing but not… well, you get the point. So I have to really focus on what makes me money and will continue to make me money going forward. So I have compiled a list of apps that make web design and development on the Mac possible for me.
-
TextMate
There is text editors and then there is TextMate. Renowned for it’s unparalleled abilities to handle a seemingly limitless set of languages, TextMate makes writing ANY code fast and painless. I use TextMate for every bit of text editing that I do, XHTML, CSS, XML, PHP, SQL and javascript, just to name a few. It’s not free but you will agree that there is no other text editor that comes close to TextMate.
-
MAMP
If you are already a pro web designer you are already aware of the need for a live server environment to test out whatever systems you happen to be developing at the time. You also no that uploading to a remote location is time consuming and working SFTP, SSH or WEBDAV can be unstable. You best bet is to have a local server, but if that is not within your means (or know-how) then you need to look at MAMP. MAMP is a nicely bundled package of MySQL, Apache and PHP that allows you to run a web server safely on your own computer. Though Apache and PHP are already included on you Mac, they tend not be as current as those found in MAMP. MAMP also allows you to quickly change your servers from one project to another to keep your perceived root URL common across all your local web work. The best part is, the only version of MAMP you really need to get this done is free.
-
Safari
Don’t hate for this. I don’t mind FireFox and I think FireBug is great but to be honest I never use either one on a regular basis. Safari, on the other hand, in an indispensable tool for me. By enabling the developer features of Safari I am able to peer into the DOM for those tricky to view javascript behaviors and see what is really happening on the client side. Safari, of course, is include with your Mac operating system.
-
PhotoShop
What is web design without the design? There are a ton of free options out there, but lets be honest, there is no substitute for the real thing when it comes to mocking up proposed web layouts. I agree PhotoShop is outrageously priced but in the grand scheme of things, if you are getting paid for your work then the cost of this app is nothing more than a tax write-off at the end of the year.
-
Parallels
You can dispute me on this choice because I honestly have no experience with anything else. The work involved in getting 3 valid VM’s working for the purpose of testing 3 related and equally crappy browsers, IE6, IE7 and IE8, leaves me with no interesting in going through anything remotely similar in the near future. But my point is this, you need to have a way of testing Microsoft’s Internet Explorer, version 6, 7 and 8 and whether you do this via Parallels or VMware is of little consequence to me. It needs to get done all the same. The cost of each is comparable to the other.
If the above list is all you ever invest in for your web design and development career then you are in excellent shape.