I decided to throw some old code through FxCop for giggles.

So, my code is bad right?

No Comments. Leave one?

Hi,

I thought I’d give a short demo of how to get serial output from a Raspberry Pi, as I just did for mine. This is useful for boot failures before you start getting graphical output as usually the UART is initialised before the OS even starts booting (this is true for other boards, but I have no idea if this is true for the funky bootloader magic that the Pi has). More importantly for me, serial is also easier to work with, as it means I don’t need to unplug the keyboard/screen from my development machine in order to interact with the Pi. This way the whole board operates with just 2 wires plugged in, both of which I can feed back to my development machine.

Note!
If you choose to follow these instructions, you can risk breaking your board – don’t do it unless you’re confident you understand what is going on, and the risks associated with it. I take no responsibility if you damage your Raspberry Pi in any way after following my instructions. This is not best practice, it’s my personal hack so if something I say or show looks dumb, apply common sense and don’t do it!

That aside, lets get down to business!

All you need is the following:

• Your Raspberry Pi
• An SD card with a valid OS image on it.
• A micro USB cable or standard power supply.
• A 3.3v FTDI board such as this one: (link)
• 3 wires to connect the FTDI board to the GPIO header on the RPi.
• Some needle-nosed pliars.
• A mini USB cable for the FTDI board
• A serial client such as putty: (link)

Ok, so you do actually need quite a lot, but never fear, it’s actually rather simple. The first thing you want to do is not kill your Pi. Make sure your FTDI board is a 3.3v version, or you’ll probably regret it. The second thing which you’ll need to watch out for is that the wires connecting the GPIO header to the FTDI Basic board don’t touch each other (or any other GPIO header pins). This is a simple hacky way to get the serial up and running, if you intend to use it long term, you may want to consider a less risky way of connecting the FTDI board to your GPIO header. Accidentally shifting it and allowing wires to cross might break your board, so I only recommend it for short term use, and in an environment where the board wont be at risk of being moved much at all.

So, with those caveats taken to heart, take a look at this page to get information on the GPIO header: (link). What we’re really interested in here are the GND, UART0_TXD and UART0_RXD pins. Also named 0V, TX and RX on that page. Tx and Rx stand for “Transmit” and “Receive” respectively, it’s important to note that “Tx” on the FTDI board should be connected to the “Rx” on the Raspberry Pi, and that logically “Rx” on the FTDI board should be wired up to the “Tx” pin on the Pi. (While GND keeps it simple and just connects to GND.)

Leave your Raspberry Pi unplugged from your power supply for now. Take your wires, and strip insulation from both ends. Try to limit how much you strip from the ends you’ll attach to the Pi, for obvious reasons. Leave enough that you can grip the end of the wire in your needle-nosed pliars and wrap the wire around the end. This will leave you a nice loop of wire to slide onto the GPIO header. Leave the end that is to attach to the FTDI board straight. You can tighten the loops in the GPIO end of the wires to prevent them touching other GPIO pins by squeezing them a little bit with your pliars. You should ensure that the wires sit tightly on the GPIO headers so you get a nice stable serial connection to your development machine. At the end of all of this, you should have something remotely resembling this:

You can then plug the straight ends into the correct location on the FTDI board, remembering to match Tx->Rx and Rx->Tx. Which should look a little bit like this:

It should then be possible to plug in the Mini USB cable and link it to your development machine, in my case this was running on Windows 7, and it promptly recognised the USB Serial device and installed the driver:

I was then able to connect putty, setting the baud rate to 115200 and turning off flow control (and leaving all the other settings at default). In my case, the Serial port attached itself to the Windows “COM3″, so I told putty to connect to that. In Linux this will possibly attach to /dev/ttyUSBX. Regardless, putty should be able to open the serial connection without the Pi being powered on, and it should wait patiently for some data to start being sent down that link.

You should then be able to insert your SD card (if it’s not already in the board!) and power it on. If you haven’t short circuited anything, it should spring to life, and text should start being spewed out by putty. Once the device finishes booting, you should be able to use the keyboard on your devlopment machine to log into the board and start interacting with it.

Enjoy :)

No Comments. Leave one?

One of our clients presented an interesting problem today: they wanted a block to be hidden from view for users who were logged out when the content was unpublished. To start with, I wondered “why the heck do you need to do that, it’s unpublished so they can’t see the node anyway”, only to actually test it and realise that no, they couldn’t see the node, but they could see the block because the block was not the node.

And since the block had tabs that held the content, it needed to be hidden.

Edited: To clear up any confusion (there has been some on Twitter), the majority of this client’s userbase is anonymous. In fact, the only people with accounts are the admins. Therefore, it’s not possible just to set the block to be visible to only authenticated users. The block itself has tabbed information – it holds most of the information on the page… so while it’s generated in node/xx/edit, it’s not actually the node, it’s a block outside of the node … and yeah, basically this was the only solution :)

Anyway, the long and short of it is that I spent an hour trying to work out how the heck to go about it, but couldn’t find any decent reference point online anywhere. So here I am – Drupal saviour to the rescue – woo!

First things first: set up the block

My first port of call was to check the standard block visibility settings. Unfortunately, “show only on published content” wasn’t one of the options. So under the “Show block on specific pages” option, I picked “Pages on which this PHP code returns TRUE”.

Excellent, time to start coding :)

The next thing was to think about what the code was going to do. Pretty straightforward: check the user ID to see if the user is anonymous, then check the node status to see if it’s published. So straight away, I wrote this:

<?php
if (($user->uid == 0) && ($node->status == "0")) {
  return false;
} else {
  return true;
} ?>

Ta-da! And done! …right? Apparently not. That didn’t work for me. So on to the next step.

Grab your global

I’d forgotten a key bit of code:

global $user;

Which was kinda stupid if I’m honest. How I didn’t realise I’d missed that sooner, I don’t know. Let’s just blame the, um, weather or something.

That gets slipped in after the opening <?php bracket.

But still no dice: it really didn’t want to work. Cue half an hour of scratching my head, trying to work out why the heck my if statement wasn’t working, why the block was either not showing at all for users who were logged out regardless of published status, and so on and so on. Then all of a sudden I had a lightbulb moment. I’d grabbed the $user variable … but where was $node->status coming from? …D’OH!

Add the node information

It all seems so obvious now!!

$node = node_load(arg(1));

So use Drupal’s node_load() function, use the first argument from the URL, and we’re golden.

Just for reference, the URL runs like this:
www.example.com/node/111
So it grabbed 111, which is the node ID.

Now the code knew to look for the status of the current node, and then all of a sudden, the code started to work. Excellent! That got slipped in after global $user; and I was away.

All together now

<?php
global $user;
$node = node_load(arg(1));
if (($user->uid == 0) && ($node->status == "0")) {
  return false;
} else {
  return true;
} ?>

And there I had it: a nice tidy little piece of code to hide a block on a page if it was unpublished and the user was logged out. Whew.

No Comments. Leave one?

Yeah okay I’m not really sure what I was going for with that title but whatever I like it okay?

Yesterday Opera announced it will begin supporting -webkit- prefixes. Excellent! Actually, according to most of the web, not so excellent. Personally I’m sort of on the fence about the whole thing.

Let me start by saying I don’t like using vendor prefixes. They are messy, they vary from vendor to vendor, and they just add unnecessary bulk to a CSS document. That being said, I do appreciate why they exist – so that different browsers can implement different versions of what may be a working draft of a specification. And while I don’t like using them, in the interest of a decent browsing experience and making the web available to all, I’ll always include both the prefixed and the non-prefixed versions of rules.

For example, for the new iteration of the Herbal Jazz layout, I’ve got transitions on the links. You hover, they fade to the new colour, you leave and they fade back. Pretty! So how would I go about doing that?

a:link, a:visited, a:hover, a:focus {
    -webkit-transition: all 0.15s linear;
       -moz-transition: all 0.15s linear;
        -ms-transition: all 0.15s linear;
         -o-transition: all 0.15s linear;
            transition: all 0.15s linear;
}

So that’s a prefix for Webkit, one for Mozilla, one for MSIE and one for Opera, as well as the non-prefixed version for when vendors drop support for the prefixed versions, as Firefox has recently for border-radius. (It has in a recent version of Nightly, anyway. That caught me out and made me realise how sloppy my coding was even a few months ago, when I included only prefixed versions of rules. BAD Sophie! BAD!)

Now raise your hand if you’ve ever visited a site in Firefox, or on IE or Opera for that matter, and something that you know should transition prettily – because it did when you took a look on your iPhone – doesn’t, because some designer or another has only included the -webkit- prefix. Hell, it doesn’t have to be a transition. It can be a gradient background, or a transition, or the text has vanished because they set the colour to transparent with a text-outline, or …

Yeah … it’s probably happened to all of us.

So now Opera are taking things into their own hands and, rather than making a stand and removing the vendor prefix altogether – which is something that a lot of designers are vying for – they’re adding support for -webkit- prefixed rules. Better? Or worse?

Why not just get rid of vendor prefixes?

Simple! Perhaps the best case I can think of off the top of my head is CSS3 gradients. Let’s take a look at some code generated by the Colorzilla CSS Gradient Generator:

.gradient {
    background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#1e5799), color-stop(100%,#7db9e8)); /* Chrome,Safari4+ */
    background: -webkit-linear-gradient(top,  #1e5799 0%,#7db9e8 100%); /* Chrome10+,Safari5.1+ */
    background: linear-gradient(top,  #1e5799 0%,#7db9e8 100%); /* W3C */
}

I’ve removed the superfluous declarations for now, and left it with the -webkit- and non-prefixed versions.

And would you look at that: the webkit syntax changed. To start with, it was different from the specification draft. Now, what happens if everyone was implementing the same rule – just linear-gradient – but each browser interpreted it differently? What would happen if the spec suddenly changed and everyone was doin’ it wrong? It would get awfully confusing, trying to debug why your gradient looks wonderful in webkit but goes backwards in gecko, even though the code is identical.

Vendor prefixes are annoying and a pain in the arse but they make life that little bit easier until features become standardised. And until all vendors group together and start working on moving the web forward as a group (yes, MSIE, I’m looking at you too), we’ren ot going to have a chance nor a reason to get rid of vendor prefixes.

So why support -webkit-, not -moz-?

Let’s have another hands up. Who has an iPad, or an iPhone? Who uses Safari on those devices? Okay, now who uses Chrome on a desktop? Or how about Safari on your iMac or Macbook (because nobody, nobody in their right mind would use Safari on a Windows machine)?

Yeah, that probably covers most of you. Now hands up who uses Firefox (that’s me), or how many use IE (hopefully none of you)?

And a final question: who only implements -webkit- prefixes?

Again, that probably covers a fair few of you. You might throw in a -moz- prefix too, just for giggles or so you can say it’s cross-browser and futureproof (^TM), or perhaps you genuinely looked up the rule on Caniuse.com and found that Firefox supports it. But I bet a lot of people out there will just do the -webkit- version because you run Chrome and you’ll sort out the other browsers if people complain. Perhaps.

Really and truly, it makes sense for Opera to implement -webkit- support rather than -moz- support, because of the sheer volume of people who automatically, without thinking, add a -webkit- prefix where appropriate. Why add -moz- support when Firefox is, in this day and age, almost a secondary browser to Chrome (as much as it pains me to say it)?

But they won’t get more users!

No, they won’t get more users, but those users they have – as Bruce Lawson said in his reply on the .net article, all quarter of a billion of them – will be privy to a better browsing experience. Things that are possible in Opera already will start appearing: gradients, transitions and so on … they’re all possible, with an -o- prefix, but that prefix gets overlooked. Now, if someone’s already got a -webkit- prefix, it’ll automatically display.

And honestly, how can that be bad? You can argue that it’s making the web a more closed place, but really it’s expanding the enclosed features of the web to a wider audience. You can argue that vendor prefixes are bad but we can’t do much about that until, like I said above, the vendors all start to work together. Perhaps you can argue that Opera should have just dropped their vendor prefix but would that really have solved the problem? I’m not sure, but I don’t think so.

I’ll end this by saying that I don’t use Opera, except for testing, but it’s one of the loveliest alternatives to Firefox that I have on my computer. It is a little backwards, but it’s got a wonderful interface, it’s fast, it’s open, and the inspector is far nicer than even Firefox’s built-in inspector. I use Opera Mini on my phone, too – it’s the best browser I’ve found for mobile browsing. And now, when I do use either browser, I’ll have more of the web open to me. That’s surely a good thing. Right?

Further reading

Opera’s supporting of the -webkit- prefix by Niall McMahon

No Comments. Leave one?

Yesterday, I got into a bit of a tizz on Twitter. It all started with one seemingly innocent tweet from Luke Jones and spiralled out of control from there:

If you think Firefox is better than Chrome or Safari, there’s something wrong with you.
— Luke Jones (@lukejonesme) April 10, 2012

I shan’t bother with the comments that followed, but needless to say I was a bit hacked off by this tweet. My initial reply was lighthearted though, a simple jab to point out that I am a Firefox user, but the conversation sort of slithered into the realm of “my browser is better than yours and let me count the ways”.

While there were a few people who “defended” my corner (that there are reasons to use Firefox), Luke had a pretty strong stance that Firefox users were somehow lesser beings than those who use Chrome or Safari. Perhaps that’s not how he felt, but that’s how he came across to me, at least. For the most part I decided to stay out of it after that, while accusations and swear words (from obvious sources) were flung left and right, but it still made me wonder. Perhaps I’m being bold in making this comparison, but really: in a society where racial tolerance is encouraged, in a community where it doesn’t make a difference if you’re gay or straight, why are we still so prejudiced over a user’s choice of browser? What happened to tolerance?

Perhaps I’m just being overdramatic, but it really does make me wonder.

But it’s okay, I reasoned, because I had one thing up on them all. I had this one thing that allows me to sit high and mighty above everyone else and grin down at them in a superior way like some sort of smug cat thing. Yes, for once I was secure in my knowledge that I am better than all of them. And why is that?

Well, it’s simple. I have my browser, and my browser is the best browser out there.

Gasp!

No, honestly, it’s true. I use Firefox, currently version 11.0, and I use a few addons. At home I’m using Firefox Nightly, and on my laptop I’m running Firefox 10.0 because I have yet to upgrade to 11. I use Firebug and ColorZilla, Adblock Plus and Tab Mix Plus. I use Stylish for Tumblr and have the Web Developer’s toolbar installed. I also have a Persona installed to make my browser look pretty, and I use XMarks to sync my passwords from one machine to the next. I have an up-to-date version of Flash and Java and even Adobe Reader installed, and I use Greasemonkey scripts to make life easier on certain sites I play.

I’ve used Firefox since it was version 1.0, when Internet Explorer contracted a virus of some sort and kept popping up ads, rendering the internet unusable. I used Netscape for a very short amount of time before it was discontinued, switched to Flock at the recommendation of Netscape, then moved to Firefox from there. And I’ve stuck with it ever since.

From hideous creations like this (admittedly a screenshot from my friend, but using the same browser I was at the time):

To the slightly better-looking things I create today, I’ve stuck with Firefox. Through the ups and downs and through its memory leaks and bugs, I’ve stuck with Firefox. I’ve grown up with the browser, and as I’ve discovered new and useful tools for web design and development, I’ve added them to my standard list of “things to install when I update my OS”.

Now there’s Chrome, which is a lovely browser and useful to test in. Recently it’s had a few bugs but it’s okay. I don’t like the inspector, though. It took a long time for me to actually start using Firebug, and now I’m using that I don’t want to use something else. Chrome’s inspector is annoying and Opera’s is worse. I avoid using IE’s at all costs. Firebug does what I want it to do, and it does it well. I don’t even use Firefox’s built-in one (I disabled that entirely!).

Chrome is fast, but I’m a patient person and I accept that Firefox doesn’t load at the snap of my fingers. I don’t mind that. I can tolerate it. It’s not a perfect piece of software. Safari on Windows is unusable. I can’t even scroll using the wheel of my mouse. I refuse to use it unless it’s absolutely necessary. Opera is nice enough, and in some respects it’s nicer than Firefox, but I just can’t get to grips with it. The toolbars and context menus are backwards. I’m used to Firefox. I laugh at IE. Simple as that. IE has improved a lot but it is still awful.

My browser is the best, and it’s better than all of yours because it is my browser.

And I’ll thank you all to remember that next time you accuse mine of being inferior.

P.S. I apologise for not blogging a lot recently. I wrote a 2,000-word blog post a few weeks ago that somehow got wiped by WordPress. It was a post that was close to my heart, and I was discouraged from writing for a while. I hope I can change that soon.

4 Comments. Add yours?