Whimsical.nu

Welcome to a Whimsical Blog~

Hi, I'm Angela, a girl with a blog on five different psyches:
girl, geek, reader, writer, gamer
Choose your poison ♥

Frontend Friday: What do you do?

This is something that I’ve been wondering about for quite a while now: What constitutes “web development”, and what exactly are we called? The definition for this, ah, way of life/subset of tasks seems to differ from culture to culture, even from person to person.

I’ve come across the following, all on the subject of “web development”:

  1. everything to do with how information is presented to the user; built up of HTML, CSS, images (spriting etc), and presentational JavaScript; or
  2. everything that’s rendered client-side, which is all HTML, CSS, images, and all JavaScript, or
  3. everything to do with how and what information is presented to the user; build up of HTML, CSS, images, JavaScript, and PHP that’s served to a browser
  4. everything that has to do with the web: HTML, CSS, images, JavaScript, PHP, MySQL, web servers, etc.

Even though the web has been here for a while already, there seems to be a lot of differences between how we (who work on the web) are called, and what is expected of us. Personally I’ve always viewed web development as a mix of the last two options, basing on the phrase, “I develop for the web”. The lines blur especially when we’re talking about JavaScript and PHP. Both are programming languages, and might fall in the realm of software developers more.

As someone who works (be it as full-time work, freelance, or as a hobby) on the web, what do you consider part of what you do? Let me know in the comments!

8 Comments

Frontend Friday: Tools of the trade

I’m finally pushing through with an idea I’ve had for a while: Frontend Friday! Every Friday, I will be posting an entry about frontend development work, which includes topics on HTML, CSS, JavaScript, and basically anything related to the implementation of designs and UI on the web. These may be simple solutions you might know about, or weird experiments and topics that concern those who code layouts, whether done as a hobby or as part of work.

For the first Frontend Friday post, I’ve decided to write about a topic that’s rather central for all web developers: the tools that we use. We all use different programs and extensions and scripts to help us code up a nice layout for our websites. I wanted to share some of mine, and I hope you find them useful.

My top 7 tools:

  1. Aptana Studio

    I’ve been using Aptana well over a year now, and in fact I wrote a review about the web IDE before. Because it stems from Eclipse, and Java, it suffers a bit of lag especially when working with large files; I wouldn’t recommend using it for that quick 30-second style fix on your website.

    But working on websites that contains quite a few bells and whistles, I find Aptana to be quite helpful. The Project pane stores all ongoing projects, the Validation tab is quick to look up typos which result in syntax errors, the Outline pane makes jumping between functions and HTML nodes a breeze, and Code Suggest is always great to have around. (You should take a look at my review if you want to know more; while that was for the beta version, it’s still relevant.)

  2. Firefox

    Yes, Firefox just had to be there. I will admit that as of late I’d been very frustrated with Firefox’s memory-hogging practices and annoying lag, and if it weren’t for Firefox being insanely great for web development, I might have dropped it for the faster Safari. Firefox is a great standards-compliant browser, plus it provides an avenue for a plethora of web-developer-friendly tools, some of which are…

  3. Web Developer Toolbar

    Chris Pederick’s Web Developer Toolbar is impossible to live without. It’s lightweight and contains a lot of helpful tools: disabling cache to make sure you see your CSS updates, cookie manipulation, CSS lookups, markup and style tools for debugging, browser resizer, viewing generated source (for all those whizzy JS things), and more. If you’re a developer and you don’t have this on Firefox yet… what cave have you been living in?!

  4. Firebug

    Actually, Firebug vied with the Web Developer Toolbar for the “must have” spot, with the toolbar winning simply because it’s lighter and more mainstream: even if you’re a hobbyist making personal websites during your free time, the toolbar is useful. Firebug is also a must-have, but mainly for more heavy duty stuff, and especially for debugging purposes: completely clueless what styles are messing things up on a certain element? Lost as to what is happening to your variables when running JS? Firebug makes digging into code easy. I can’t count the number of times Firebug has saved me hours of trawling through CSS or numerous alert() calls.

  5. Multiple Internet Explorer installations

    There are numerous multiple IE tools out there, but the one I personally use on my Windows test machine is TredoSoft’s Multiple IE. I really only test for IE6 and IE7, though (I should install IE8 soon, too…). It’s a bit of a pain, but that’s the way life rolls. The IE Developer Toolbar is also a must-have for IE-proofing your website. I hope they update the toolbar to include a debugger soon.

    Naturally, you will also need other browsers installed, according to what you wish to test with. I test according to Yahoo!’s list of A-grade browsers, even for my personal work (well, in varying degrees, as I don’t have multiple images of Windows sitting in my personal machine, for instance).

  6. YSlow

    YSlow analyzes my pages’ load times. I typically only use this nearer to the end of development, to check if I need to combine more images into sprites, chunk together CSS and JS, etc. It’s definitely a good guideline checker for webdev best practices, which may or may not be critical for you, depending on what you are working on.

    YSlow takes into consideration Yahoo!’s rules for high performance websites, which every web geek into making websites should read through at least once.

  7. Fiddler and/or Tamper Data

    These two are mostly useful for deeper digging into the communication between your website and the server, and may or may not be applicable for the type of work you do. I find it highly useful for verifying form submissions’ raw data and AJAX requests — you can stop the data transmission, fudge up the content, and release it, which helps you trap bugs and issues.

    Tamper Data is a nifty Firefox extension for this purpose, and Fiddler is an HTTP debugger tool, much more robust than Tamper Data. Unfortunately, Fiddler is not available on Mac OSX — I’ve been looking for a good alternative for a while now (Paros looks like an interesting alternative, but for some reason I can’t get it to start monitoring traffic).

So those are the top 7 tools I use for working with code. What are yours?

4 Comments

Enthusiast Anti-spam Addon, and allegations of jumping ship

Gabrielle wrote an Enthusiast anti-spam addon, which may be useful for those of you whose listings have been targeted by spambots. Please check it out if you have this problem, as this may work for you. Thanks so much to Gabrielle for doing this. <3

On the subject of Enthusiast, I would like to assure everybody that I have not “abandoned ship”. Believe you me, I’ve been through a lot because of Enthusiast, from disgruntled users who swear at me or my script, to people who have ripped my script and claimed it as their own. Yes, I have thought of “abandoning ship” plenty of times, and I suppose this might keep happening far into the future.

But I haven’t thrown in the towel just yet.

That doesn’t mean, however, that everything will be oh-so-fine and dandy and scripts will get chugged out of this scripts archive/tech blog at a steady pace. I wish I could, but there are only 24 hours a day, and seven days a week. I am no longer a college student, as the case was when I started Enthusiast all those years ago and virtually no one knew about it.

(I started to break down my time in an attempt to show just how scrapped for time I am, but I decided not to let it go that far.)

Enthusiast is not the only thing I have to put my time on. I have three blogs, and none of them even get updated as regularly as I like. My first love is creative writing, but I can’t even allot proper time for that. If you look at my fanlistings, a whole chunk of them haven’t even had new layouts in a year, some of them over two! I’ve even relegated to using layouts made by others in my journal (and maybe others) in an attempt to cut down on whatever coding I need to do. I’m a developer/designer, coding is what I do, but I can’t have time to whip up a quick CSS file to customize my own things. How sad is that?

Enthusiast is not the only thing I want to do. I have three scripts I want to create, one script that desperately needs a revamp (and I mean really desperately, but guess what? Enth development is still ranked higher), and I have a couple of others (featured here) that needs an update sometime soon. They’re all competing for attention, and I’m trying to manage it all, along with my work as a Yahoo, the little things we need to do daily so that we continue living, take care of my health, interact with the people around me.

That said, Enthusiast is important to me. I don’t think any one of you who are using it can claim that Enthusiast is more important to them than it is to me. It is important to you only so far as it helps you maintain your fanlistings, but Enth as an entity by itself is useless to you. You’re free to move to other scripts if you find Enthusiast lacking, I’m not stopping you.

To those of you who have shown me support, who help others with their Enthusiast installations, who have donated a little bit to my tip jar for my efforts…I thank you, from the bottom of my heart. Your show of support does not go unnoticed, and they continue to fuel the work here when times are tough. <3

37 Comments

Rediscovering PHP

So last night, armed with my nifty new font, I decided I’d get a move on with the next top-level version of Enthusiast. (Yes, I’ve started working on Enthusiast 4.0.)

(For those of you interested in it, it will probably be slow going, as whatever free time I have needs to be spent juggling between rest/recreation/social/family/other hobbies… and because I’m putting in a lot more effort in the backbone, and in usability.)

One thing I’ve always believed in is that you only get as good as what you actually do. That one might read a lot of tech blogs, a lot of white papers, a lot of those hifalutin framework blueprints… but if you don’t get down and dirty with code, you can’t expect to get better. It’s a given that the first few codes you churn out will be riddled with flaws. That’s normal, but that’s better than never getting over that simply because “I can’t fully understand OOP yet, I need to read more about it”. Ugh, get a grip, and get on with playing with code.

My first PHP project, way back when I was doing self-studying, was actually the precursor to Enthusiast. It was the script that handled my then-fanlisting, Bubblegum Crisis. After it was working, I moved on to the first “system” — an admin tool for handling my directory for NeoPets galleries. I actually put up that site, got a pretty nice following for it, and then when I weaned off NeoPets, I shut it down.

And then I started working on Enthusiast (the single-fanlisting version).

Without these first projects, I’d never have learned PHP. And this time, with PHP4′s End of Life looming in the distance, Enthusiast will be bringing me forward to PHP5. OOP, Exceptions, and many newfangled stuff in PHP isn’t new to me, but it’s been a while since I’ve actually handled PHP code continuously (almost eight months–the same time I’ve been with Yahoo! as a frontend engineer). I will be getting personal with a lot of these new things, in order to do what I need for it to do. And that’s quite exciting.

For anyone who’s thinking of learning PHP, the best way to learn really is by doing something you’re passionate about using PHP. I was passionate about NeoPets galleries; I was passionate about fanlistings. The passion drives you forward, and that’s a great thing to have.

I will probably be blogging here occasionally about new things I find out while working with PHP, or thoughts on development in general — what would you like to hear about?

25 Comments

Apache, PHP, and MySQL in Leopard

I was quite delighted to find out recently (via AJ) that Apache and PHP was available by default on my Mac. Before I got my Mac, I thought that was the case, and then I couldn’t find it and supposed there was none and got living-e’s MAMP instead.

I quickly got annoyed, because just logging off and shutting down my computer after a bit of dev tweaking meant typing in my account password. Sometimes I ended up forgetting I had it running, and Logout would stop because MAMP needed something from me. It was quickly set up, but after a few weeks of getting it (and ending up too lazy to go through the whole startup-type-password-work-shut-down-type-password cycle…go figure) I was ready to brave whatever UNIX source compiling wizardly people go through to get their machines ready for web development.

After all, I’ve never resorted to using WampServer or XAMPP (etc) when I was still on Windows. I’d always preferred installing and configuring each one by one. This shouldn’t be hard, right?

And nope, it wasn’t! I’d initially envisioned needing to compile the source and all that scary stuff, but apparently (like I said) Apache and PHP was already built in, and MySQL had a Mac OS X binary. Yay! I spent an afternoon tweaking to my heart’s content, after finding gems like these:

Here’s what I did.

  1. Set up Apache’s configuration file.

    Open up Terminal, and type sudo vim /private/etc/apache2/httpd.conf. You’ll need to enter your password, since you’re running as root. Line 114 (or thereabouts) will be where Apache loads the PHP5 module. Remove the hash/pound sign (#) (type i to enter insert mode, and escape to get out of insert mode when you’re done) at the start of the line.

    LoadModule php5_module in httpd.conf

    Optional: You can keep going and customize your httpd.conf file to your liking. For me, I did the following:

    1. Change DocumentRoot to my Sites folder (two lines to change).
    2. Add index.php in DirectoryIndex to automatically load index.php files ahead of index.html when requesting a directory.

    Save the file (type :wq when in command mode).

  2. Setup PHP’s php.ini

    Leopard doesn’t have a php.ini by default, but the default one is still there, named php.ini.default. Make a copy of this by moving to the /private/etc folder and copying that file:

    $ cd /private/etc
    $ sudo cp php.ini.default php.ini

    You might need to enter your password again. After that, you can edit php.ini (again, sudo vim php.ini…this is read-only, so remember to override vim’s warning when you’re saving and use :wq!) to change error reporting and other things you like to have PHP do when you’re developing.

    php.ini error reporting

    Note: The mysql and mysqli extensions are not enabled by default. You probably want to change that. (See lines 625 and 626.)

  3. Run Apache!

    Now it’s time to test your web server and PHP together. Fire up System Preferences, and under the Internet & Network section, click on Sharing. Check the check box next to Web Sharing. Once it’s on, you can go to the URL there, or try the ever-trusty http://localhost, to test if your settings are as they are.

    Of course, if you feel like you want to do it the geeky way, you can always run sudo apachectl start.

    Web Sharing preference pane

  4. Now let’s get MySQL up and running.

    MySQL isn’t included, so we’ll have to install that. Download a binary package and install MySQL, the StartupItem, and the preference pane. I haven’t actually gotten the preference pane to actually stop and start the MySQL daemon, but I figure it will work eventually, and it’s always nice to see it in System Preferences.

    Once they’re installed, hit sudo /usr/local/mysql/support-files/mysql.server start to start the daemon. You can try doing this via the preference pane (and let me know if it works). The preference pane also lets you toggle if you want the daemon to start automatically when you log in (which is the whole point of this exercise…but again, for some reason it doesn’t like me ;( sob).

    MySQL preference pane

  5. MySQL socket problems in PHP

    As of the time of this writing, just installing MySQL and enabling the appropriate extensions in php.ini isn’t enough. PHP won’t be able to find the MySQL socket and won’t be able to talk to your database server. This post has a good explanation why, but to summarize the fix for this:

    1. Create a my.cnf file in /etc:
      $ cd /etc
      $ sudo vim my.cnf
    2. Type the following in the file:
      [client]
      socket = /var/mysql/mysql.sock
      
      [mysqld]
      socket = /var/mysql/mysql.sock
    3. Save the file and exit to the shell (:wq in command mode).
    4. Type the following commands for the sock file’s directory:
      $ sudo mkdir /var/mysql
      $ sudo chown _mysql /var/mysql

    PHP should be able to connect to MySQL now. A word of caution:

    One drawback to this is that if you have installed the MySQL GUI tools, they will look for the mysql.sock file at the old location. You can enter the new socket in the connection dialog under More Options, there is a box labeled “connect using socket.” Just enter /var/mysql/mysql.sock.

    Another solution is to change the php.ini file to expect the socket in a different location. I’m going with the my.cnf option because I expect the MySQL will have a Leopard version out in a few days that changes the default location.

    - from Professional PHP

That’s all there was! You should be up and running in no time. I ended up taking a bit longer because of the following (which might help you):

  • My files all had wrong permissions. They were all just readable and writable by myself (the owner) and hence my web server couldn’t read them. A quick recursive chmod 755 * helped, although of course I’m wondering if there’s an easier way to get this all done. (Let me know?)
  • I installed CocoaMySQL for my database management needs. It looks pretty spiffy. I’ll give it a whirl and if it isn’t enough, I might try out Navicat, although I’d rather not need to pay for a management tool.

Edited to add: I found out that the MySQL preference pane really wasn’t working, and that MySQL is aware of this issue. I found a patch for it via Natron Designs; and yes, now, it works!

3 Comments

Development musings

Happy, hopeful new year, everyone!

Life is just barely settling down after the holidays, and I’ve been meaning to work on Enthusiast for a while now, but kind of endlessly putting it off. I want that to change, but to change that, I’ll have to do a bit of reassessment, and to pinpoint why I have lost the thrill and joy of working on Enthusiast.

It won’t mean it will be gone, as even if I feel rather unmotivated to work on Enth, I still love it and want to bring it to the next level. I’ll just have to figure out what the next level is.

Just in case it helps others out there, here’s something I’ve started reading that I feel is helping me a lot: Getting Real. A lot of things won’t be applicable to Enth (I don’t think suddenly scaling down features is an option) but I’m trying to figure out what to do with the stuff I’m reading and taking in.

9 Comments