seige

In Illustrator (I am using CS3, but the toolkit has been the same since V.1) select the STAR tool. Now... do NOT drag or use the tool interactively... simply 'click' once on the illustrator drawing area... A dialogue will appear, and ask for input... Radius 1, Radius 2 & Points Now... a *good* setting to start with is Radius 1: 100px, Radius 2: 90px, Points: 30 Once you get a good setting, you can scale the image up & down in Illustrator to the size you need. And, if you're on at least CS, you can do all your Web2 style stuff in Illustrator rather than Photoshop, as I personally find it much easier. In Photoshop, if you *insist*, you can also create stars by using the Polygon tool (vector) and selecting 'star' as it's options. Then, the same figures above are a good start point.

Ahhh a good question... It's going to need a bit of tinkering with, as there may not be universal 'all browser' ways of doing it. One way is to use InnerHTML and Divs, but if you are already quite happy about hacking around with changing images, consider using 'swfobject', which will also easily solve a lot of other problems too, such as escaping the dreaded 'activate flash now' problem quite elegantly. see: http://blog.deconcept.com/swfobject/

Because I also do graphics print work as well as web, I opt for ViewSonic digital screens... currently I have two 20" and one 22" widescreen Samsung running on the same Mac. A great setup. The ONLY thing with the ViewSonic's is they do take a while to reach full contrast. The Samsung (which was cheaper) is ready-to-go straight away, although it DOES have a weird trait of having more saturated colours near the top of the screen than the bottom—regardless of view angle. Oh... and NEVER clean your TFT display with anything other than a damp microfibre cloth, or in extreme cases add a small amount of weak detergent. I've seen more TFTs permanently 'clouded' by using alcohol or spirit based cleaners than I care to mention. On guy I know even managed to rub away the anti glare coating when he was trying to scrub off what he described as 'a dry bit of sneeze'. TFT screens are much more delicate than the old glass screens of a CRT. The best advice I have is keep a nice clean microfibre cloth in your drawer and gently de-dust the monitor daily, and clean any 'muck' off as soon as it happens. P.S... don't you just HATE clients who come in and TOUCH the screen with their greasy fingers!!! AAHHHRRGGGHHH!!! (perhaps we should start a 'pet hates' thread!!!)

Well, it's not so much an idea, as it is a fact. Worldpay are indeed slick, and big, and reliable. But, for new companies (see, I said 'new' companies) Worldpay quite rightly like to manage and control their risks by having what you may term a probationary period between accepting a payment and delivering it to you. Although, as you become more familiar with them, it *is* possible to bring the period down to an acceptible level. My comments were based (as noted) on a *new* business. For which, without company records, bank accounts etc. Worldpay will certainly not treat too well. Due to these restrictions, it's been a fair while since we integrated a Worldpay solution. In fact, over the past year or so, we've migrated several 'unhappy' clients out of Worldpay to their own bank's solutions (HSBC/Barclays etc.). Therefore, my information may be a little out of date

AS with most companies... if you call them and show a modicum of intelligence (i.e. you can't be blinded by them using jargon-laden sales spiel) there's a fair amount of negotiation which can take place... Bear in mind the Rackspace hosting is over 2/3 of our £400 monthly hosting spend, and yet caters for almost all of our critical stuff, it's little wonder that we go grey and bald a LOT slower than other people we know who are spending 1/10 on hosting. The pros are simple: no messing, no fuss, no 'learning curve'. Just get in touch and it's sorted. The price is well justified, because as the years go by, one headache I can do without is listening to the bull$hoot given by an offshore callcentre when something goes wrong. Downtime, headaches, etc. are just not worth it if you want to do it right.

Over the last 15 or so years I've been involved with the internet, I've used practically every hosting company out there. However, with all the horrors I've had in the past, I can safely say that by using Webfusion/Pipex and RackSpace for the past 4 years, I've had almost no problems at all. (The downside is, I host about 100 client sites, which means I'm outlaying about £400 per-month alone for hosting. But... bear in mind that this is a CHARGEABLE item, it breaks down to a very reasonable sum to each client...) AVOID cheap hosting like the plague. In the long run, it's just not worth it if you have clients relying on your services. It can make or break you, trust me!

If your site relies heavily on CSS, you want a failsafe against the dreaded user-configured browser (i.e. on a machine where the idiots have installed every single hack, toolbar or magazine cover disk utility therefore making their setup FAR from normal!!!). One easy, but ugly way, is to provide a link somewhere which says "Problems viewing this page?"... which switches to an alternative stylesheet. In a recent incident involving a trading site, we had a lot of horrors with whole DIVS being shown outside the document area... i.e. not visible. This was not the end of the world, but it meant the user couldn't access their cart to checkout! Which WAS quite an inconvenience. Although we'd tested the site on several browsers, we discovered later (by trial and error!) that due to the way Explorer 'remembers' font size settings, the DIVS were being pushed out of the main container by a rogue . It would seem, therefore, that having a 'failsafe' is the best way to get around the various non-compliance of MS browsers. If only the world used Firefox/Mozilla...

Well, I have three Macs, and each has a different keyboard. 1 has a £, one has a Euro, the other has a HASH!!! Eeeeek. Anyhow, to get the keyboard viewer in OSX (I'm in Leopard, but I guess this is backwards compatible...) 1. Open system prefs 2. Go to the 'international' prefs pane 3. Hit the 'Input Menu' tab 4. At the top, there's a list of items to include in the input menu. Choose the 'character palette' and 'Keyboard viewer' (i.e. check their boxes) 5. At the bottom of the page is a checkbox: 'Show input menu in menu bar'. Check it. 6. Back in the tabs, go to Language, and make sure you select your *native* languages Now, after quitting system prefs, you'll see a little flag up in the right area of your menu bar. Click it, and there should be an option for 'keyboard viewer'. You can modify the view by holding modifier keys on your real keyboard, like shift or alt. The other item in the menu dropdown is the character pallette... VERY handy for hunting down glyphs in various typefaces. Enjoy!

Blimey... and as if by magic, they start arriving today... had two Xmas cards, one of which had one of those 'snappy boxes' inside which popped out and almost gave me a coronary. And, both of this are *clients* and not suppliers! Awww, me feels all warm inside... (I knew I shouldn't have had those fajitas last night)

For the main php try: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> It seems you're mixing to many declarations. Also, you didn't use an XHTML doctype And... those backgrounds are way too distracting when there's text to be read!!! Try lowering the contrast...

Hard shadows are your main problem here. Direct point-light will always do that and it's undesirable! Really you need to construct a sort of softbox for the lighting. Easiest way is just to diffuse the light using greaseproof paper or something... i.e. take a large sheet of semi translucent paper, and mount it between the light and the subject. I love your impromptu infinite curve! For about £30 you can get a 'web photography' mini light box plus several bits of kit for macro/small items. A really great addition to your photography arsenal on a small scale. But, nice and colourful compositions!

This is a really nice article. I agree with what Thomas says above... however, I'd also stress that for people learning PHP, showing them the INCLUDES methods and theory before getting dirty with functions is a great way to teach them how re-usable snippets work... and my reasoning behind this is that it is a very simple and 'visible' way of making the point. And of course, with *new* coders, you don't have to initially get into the complexities of variable scope when using includes, so again, another great reason why it's much easier to understand. I've supervised the training of a couple of PHP coders now—guys who were mainly designers but needing to dabble back-end—and I've gone down the 'learn includes, THEN functions, THEN classes' route. The great thing about this is that down the line, you can then teach that an include, and its constituents, can be written as functions for even MORE functionaily. Last night I showed on this forum how a member could consolidate the coding they were using by utilising their include file better. The way I WOULD have shown this would be to use functions—but the guy had already said he was quite new to PHP. So, a great thumbs up for this article—but remember, although there *IS* a right way, and there *IS* a wrong way, it's sometimes better to take tiny footsteps rather than a leap in order for people to understand. Of course... The other great thing about includes is that they can be conditional... and this is great. For instance, I remember the not-so-distant past when HTML in it's most basic form was the only real way to code. Sites predominantly used FRAMESETS, and CSS wasn't even heard of. Large site projects which had, for instance a common navigation or footer, would tuck them into a frameset. For those of you unfamiliar with the now almost obsolete (thank goodness!) framesets, I will explain: a frame is a container, which can have a page loaded into it. So, imagine an index.html page which consisted of no content, just a description of 3 frames: the top frame (header & nav), a middle frame (body content) and a bottom frame (the footer). Then, the index page would reference another file for each FRAME... i.e. the top frame could include 'header.html', the middle 'page1.html' and the footer 'foot.html'. This was a great way of re-using page code... and if, for example, the footer info needed changing, you only need change it once and ALL your site pages would automatically reflect that change, as the footer file is dynamically loaded as a page component on each page in the site. Now... includes can work in a very similar way. If you have, for instance, a similar layout model for the whole of your site, you could add a 'footer' include to every page to save you re-writing it. And a header. So, why not just wrap your page in a header and footer include? Think of it like this: <html> <body> <? require_once('includes/header.php') ?> <!-- body content for this page --> <? require_once('includes/footer.php') ?> </body> </html> Working this way is fine for code junkies like me, because I can visualise the page layout. But it's a little bit harder for GUI workers with WYSIWIG web editors, as the page content will not display in your editor. Another good include... ...and one which I use on practically every dynamic site I do is the 'includes/setup.inc.php', which is called RIGHT AT THE TOP of the page, before any HTML or headers are output. This include handles all the doctype HTML, the opening HTML tags and opens any DB connection, plus defines any common functions. It also handles post data cleaning, page checking, and meta tags for description, title, stylesheets, java etc. And, because it is used universally, it ensures your site is consistent. A bit of a conlcusion about includes, and some other handy tips... In short, includes shouldn't replace functions: they should CONTAIN them! When starting a dynamic site, the usual page construct for me is: <?php require_once('includes/setup.inc.php'; <body> <? require_once('includes/header.php') > <!-- page content --> <? require_once('includes/footer.php') > </body> <? require_once('includes/terminate.php') > So... the tips here are: terminate.php closes anything, including DB and tags created by the setup.inc.php include, such as the 'HTML' opening tag. The terminate file can also include error tracking scripts, etc. Now, another tip... REMEMBER that when you include a file, it's root paths and variables are all relative to the parent file, even though the includes may be in a separate directory, or even server. This has been the simple solution to MANY problems I've had over the years! For instance, imagine this construct in a file called index.php: include('pictures/gallery/imageshow.php'); Now... the picture this file calls is within the 'pictures' folder, which resides at the root level, the same as the index.php file calling the include. Providing a relative path to that picture in imageshow.php include will NOT work, as using a RELATIVE path will be relative to the PARENT PAGE and not the INCLUDE. Because the include is buried deeper, a relative path within the include file would have to escape the 'gallery' folder first!!! It's very good practice to use absolute URLs in sites anyway, and in this instance, it would sort out the problem. But more about that another time, cos I need coffee!

Well, frankly I'd not rate WorldPay... they hold your cash, for a start! Eek! Wise words above... you can't just code this stuff and hope for the best, as almost all of the payment gateways have their own methods. Gladly, most of the decent ones also provide APIs/code snippets for most language constructs to help you integrate. But they only do this once you've signed up. Frankly, I'd say have a look around and decide on a gateway provider, and then go from there. Build the cart system with the gateway provider in mind. My choices, in order of preference for a *first time dabble* with gateways would be: 1. PayPal... easy to integrate, easy to understand, easy to administer 2. Protx... harder to integrate, harder to understand, but economical in the long run for larger throughput 3. WorldPay... can be tricky to integrate, tends to look non-savvy, and has a three week hold on your money before you get it 4. Your own bank's system (such as Barclaycard Merchant Services)... VERY hard going, but ultimately rewarding as it can integrate with your current merchant card services account... i.e. current payment by card 'hardware'. 5. Take card numbers securely, process manually off-line... if you already have a card payment machine, this is an option... you can take all the details you need on your own site (SSL is the ONLY way to go) and then process the transactions by hand. Great for sporadic transactions, like one or two a day, and cost effective as it's already integrating with your current setup. I am quite sure that if you are having to even *ask* about these methods that you've not used payment gateways before. Therefore, PayPal is by far the simplest and GUI based method to get to grips with. Plus, it's easy to set up.

Ohhhh dear... is it *that* time again... I've just had a squint at some stats from a few Google datacentres, and there's a bit of variation. Perhaps an update of sorts is rattling through the system. Don't panic. Give it a few days, and it may just stabilise.

If you have the 'tools', such as Illustrator, with which shapes like this are most easily created, then you're laughing. Let me know what apps you are working with—notably vector ones—and I'll throw you a line.

Now that's MUCH better, and way more informative... All I would suggest now (being the pain in the butt that I am!!!) is that you somehow indicate to punters that the thumbnails are clickable... perhaps a tiny magnifying glass in the bottom right hand corner of the thumbnail? Or, even a footnote of "Click a sample to enlarge it" or somesuch. As previously suggested, if you're touting for work, perhaps a link under each thumbnail "Click to visit site". This all makes it sound like it's going to be complicated, but trust me—you've already made a huge difference to the site—and by adding interactivity it will just get better!

Nobody broke it... it's an artefact of code being generated by the santa smiley So, it's more a case of the ADMIN broke the forum!!! (Hey, it's my first day here, and I'm already throwing accusations at the hosts... see how much at home I feel???)

Far too many people who entered the digital world only recently have no concept of the bit depth of an image and why it's there. I think the common misconception is that a 16 bit image is better quality etc. Well, for web work, this isn't really an issue, and always set the image bit depth to 8. That way, ALL the Photoshop effects, filters and save modes will behave as expected. (Sheesh! I remember using Photoshop in greyscale on an old Mac 512... now that WAS a challenge!)

Eeek... I really don't quite know what to make of that. Some part of me deep down knows it is just plain weird, but another part of me knows to just accept weirdness as part of daily life! Personally, I've never had to mention that I've had the squits... but if I ever see a small Japanese girl in a lycra bikini doing a weird dance, I will make sure I pass her some Andrex and get well out of her way... See. That's advertising working for you right there.

When using require/include, any variables in the calling page/script are inherited by the include. Therefore, here's how I'd do it... 1. In the include php file which connects to the database, include a check, much like the following... if (isset($validate)) // does the variable $validate exist? { $query = "SELECT * FROM users WHERE user_id=$id"; $result = @mysql_query ($query) or die (mysql_error()); $myrow = mysql_fetch_array($result, MYSQL_ASSOC); if (mysql_num_rows($result) <=0) { header("location:http://server.com/errorpage.php"); // redirect to error page, skipping the rest of the original page } // nothing else to check, so the include file finishes and the rest of the original page continues parsing } 2. At the start of the page requiring ID checking... BEFORE the call to the include page (the DB connect)... $validate = 'yes'; // validation mode 'on'... by including this variable and giving it a value, the DB connect script also checks for a valid $id Using this method, the chunks of code needed to do the check can be accessed and checked on any page just by setting the variable '$validate' before calling the DB connect script. Furthermore, because the scope of the variables used are local to the page, the values generated in the '$myrow' array are accessible to the page without having to duplicate code. Re-using code like this can be a fantastic way to keep pages clean, and also save on a lot of work! Incidentally, this is a *simple* method to achieve this result. There's other ways, as I am sure you will discover, which are in some ways neater, but if you're new to PHP, the method I describe above should make sense, and by looking 'which bit does what' it should teach you a bit about nesting includes and how they are useful.

It would seem that it's my pleasure! I've never been to a forum with so much good spirit, and trust me... I've frequented a few! I have to say you guys have gone out of the way to make me feel at home. And again, apologies for the posting frenzy, but I am at my machine for about 12 hours a day (until the Wife starts screaming!) during work days, so it kind of helps me de-stress, and take a breather.

Damn, it's so nice to be in the company of fellow geeks

Over the years, I've learned a few tricks, and one of them is to wrap these checks into functions. It means you can call them at the head of each page (before output of any headers) to ascertain a redirect before the rest of the page is parsed, should the 'id' field not correlate to any records. For instance... why not build the ID check into the SQL connect script? That way, it's reusable, and the page only continues loading and parsing if that stage is reached. For security purposes, this is a good idea, plus it's also 'neat and tidy'. Also, it means you can have a generic 'Hang on, something went wrong' page, rather than relying on errors being generated in-page. Just a thought. Another minor note... never use the variable ID in a $_GET or $_POST... it can cause unwelcome problems as it's a 'common' name which people can misuse as a backdoor. Try and use 'visitor_id' or something more descriptive.

// cat among the pigeons mode: on Well... personally I think the stripes at the bottom are well balanced. They are the 'M' series stripes, are they not? That way, I would leave them be. Because the info is not 'page content' as such, and the link to your own site is so prominent, I'd just create a DIV called 'footer' with common text colour values for everything, INCLUDING the URL (remember: the L V H A rule, and make ALL the text except the HOVER the same!) See the attachment... This moves the type out of the main content area, and out of the way. Still readable, still indexable, and still clickable. I would also recommend making the footers' text anchor to the alternating pages... this helps keyword linking between the pages in the search engines.

OK, if we're being REALLY picky, on the 'I have worked with..', technically an ellipsis has three dots... never more, never less.