March 20, 2007

Hiring a web programmer or designer -- some things to consider

Over the past few months, we have begun to SSC a relative influx of departments, centers, and programs redesign their web presences. Some are looking for simple facelifts, while others are thinking of a soup-to-nuts relaunch. Everyone knows that for many of these organizations, the web presence is the first (and sometimes only point of contact for clients, customers, and other interested parties. Your website is important: we understand that.

With this increased demand for website refreshes and enhancements, we're also seeing some trends in how individual groups (the departments, centers, or programs) go about hiring the people to do the web work, and frankly - it's kind of frightening.

Here are things to think about before you hire that special someone to do your web redesign:

  1. Are they familiar with the tools that are supported in SSC? Our webservers run the Linux OS, using the Apache webserver, PHP middleware, and the MySQL database system. If you want the slightest bit of dynamic functionality (something database driven, or with embedded scripting on your pages) these are some of the fundamental skills your would-be consultant needs to have.
  2. If they're familiar with our standard toolset, that's a good start. But how good are they, really? We've run into folks who advertise themselves as database experts, but don't know the difference between a foreign key, a primary key, and Key Largo. We've seen would-be web and database programmers who don't know how to dump a database table, or write code in PHP. Apparently, one person's 'familiarity' is another person's 'expertise.' We've even had folks ask for administrative access at the OS or database level (a BIG no-no for any professional, as far as I'm concerned...)
  3. What experience do they have? Is web development something they do for a living (not often the case with students)? Have they any formal training in the technologies we use? Here's an analogy I like: you wouldn't ask your local Boy Scout who's got his woodworking badge to design and build your back deck; why would you hire someone with little real experience to build the window through which the world looks at your life's work?
  4. Are they expecting to use software we don't provide or support? If so, what's the support model? I inherited a really elegant, bespoke web application for one of our departments, but had to learn how it was built line-by-line, as there was no provision for ongoing support by the department (to be fair, the original developer was tremendously accomodating and gracious; unfortunately, for every one like him, there are five who won't take your calls after they 'finish' the job). In the past year, I've seen more than one organization flailing about because the web developer they hired threw a non-supported (by us) system on the server, loaded content, and then disappeared. No training of administrative staff, no documentation -- 'Oh, it's all on the web.' Not comforting when faculty are beating down your door wanting to update their CVs...
  5. What are your expectations? Have you thought them through? Have you given serious thought to how you want your web presence to fit into what I have to call your 'business processes?'
  6. How soon do you need the work done? Chances are, if you find yourself needing to complete a project tomorrow, it's not likely to be well-planned, executed or supported. And that's a bad thing.
  7. What's your budget? Are you trying (as we all are, really) to do the web project on a shoestring?

So what to do? Well, there are a couple of things that you can do. First, contact your LSP and bring them into the conversation. Better yet, bring your LSP and your friendly, neighborhood UNIX admin into the conversation. Together, we can begin to bring your goals into focus, and figure out whether or not we already have a solution in place, what expectations are reasonable, how to plan for ongoing maintenance and support after the project is finished. If you like, we can help you in locating and working with an outside consultant; we can also interview (as part of your interview process) the folks you're considering, and give you feedback as to whether they can meet our standards for having access to our systems. But even if it's just for an initial consultation, bring us in. You'll need to deal with us to get your contractor access to our systems, so it's better to bring us in at the front-end, rather than at the back.

Additionally, there are discussions within SAS regarding codifying which web products are officially supported; this can help you narrow the decisions you have to make, so that you (and your consultant) can spend more time on application logic and design.

Blogged with Flock

Posted by ssc_upenn at 11:15 PM | Comments (0) | TrackBack

January 11, 2007

Something to think about if you forward your work mail to Gmail...

Firms Fret as Office E-Mail Jumps Security Walls

Posted by ssc_upenn at 8:25 PM | Comments (0) | TrackBack

November 30, 2006

Secure Encryption on the Mac -- a nifty How-TO

This is a pretty good tutorial for creating encrypted space on your Mac, without going the whole-hog route of using FileVault to encrypt your entire Home directory.

Macworld: Secrets: Encrypt files for safety

technorati tags:, , ,

Blogged with Flock

Posted by ssc_upenn at 1:19 PM | Comments (0) | TrackBack

October 26, 2006

Another course for would-be Cluster-jocks...

Introduction to Beowulf Design, Planning, Building and Administering

The ARC team at Georgetown is putting this course on November 7th through 10th in Washington. At $800, it seems like a reasonable deal. If I only hadn't already spent my travel allowance...

;-)


technorati tags:, , ,

Blogged with Flock

Posted by ssc_upenn at 6:17 PM | Comments (0) | TrackBack

What does 'Blogged with Flock' mean?

At the end of your most recent blog entries, I see the text 'Blogged with Flock' -- what does this mean?

Why don't you look here and find out...

technorati tags:

Blogged with Flock

Posted by ssc_upenn at 12:45 PM | Comments (0) | TrackBack

I wish I had a wiki, I wish I had a blog

So guess what? We support blogging and wikis now.

Don't everyone come rushing in at once...

If you have a problem you'd like to solve -- you want to have a project discussion space that can easily be referenced, or you'd like a somewhat easier to manage way to publicize events than editing a webpage -- contact us. It might just be that a blog or a wiki could be the way to go.

But here's a quick rule of thumb to get you started thinking about this:

Blogs are for data that gets stale quickly, Wikis are for data that gets better with age

What does this mean? Typically, a blog entry is a fire-and-forget affair -- "So-and-so is speaking at the place at 5pm on Friday evening" -- which has a fixed useful life (or, as geeks would say, a short TTL); a wiki entry is more along the lies of "These are four errors users make in configuring their mailing lists on mailman.ssc.upenn.edu" (and be assured, there are many more than four ;-) ) -- this entry could be edited to add detail, viewers could (if they're authorized) post responses, additions, clarifications.

Another difference between the two is that a blog generally has a small, fixed set of authors -- I write the UNIX blog, for example; a wiki can, if one desires, be edited by anyone who reads it (although the list of approved editors -- notice the difference in terminology -- can be more narrowly circumscribed if circumstances dictate).

If I get my way, perhaps in the spring of 2007, we'll be able to move to a more unified online documentation system (which is, if you think about it, a lot of what blogs and wikis can do) -- both in terms of appearance and functionality.

technorati tags:, , ,

Blogged with Flock

Posted by ssc_upenn at 12:39 PM | Comments (0) | TrackBack

June 16, 2006

Setting up a Linux system to use software RAID

This is a really great link on how to do this 'by hand.' I recommend that you do every task at least once 'by hand,' so that you can have a sense for what actually happens when you use a gui or script to accomplish it. In this case, the task is migrating a single hard drive system to use RAID 1 (mirroring) through the in-kernel software RAID system.

http://http://www.debian-administration.org/articles/238

Posted by ssc_upenn at 1:13 PM | Comments (0) | TrackBack

February 22, 2006

Denying access if SSH is dictionary attacked

If you're running your own UNIX box (Solaris, Linux, OS X), you may notice (if you ever peruse your SSH logs, often /var/log/secure) sections of your logfile where the same host attempts to connect to your server via SSH with an assortment of common usernames and common passwords. This is what is known as a dictionary attack.

Fortunately, there's a program called DenyHosts which is designed to deal with this very problem.

Here's an article on DenyHosts from Linux Today (original article at How-To Forge).

Posted by ssc_upenn at 12:03 PM | Comments (0) | TrackBack

April 1, 2005

Who are you? Where can you be found?

Well, who are you? Where's your office? What if we have a UNIX problem?

My name is Chris Couples, and I'm the UNIX sysadmin for SSC (my actual title is 'Senior Systems Programmer'). I've worked with UNIX for ten years, and professionally for seven. I got my Master's Degree in Political Science from Virginia Tech, where I began playing with the internet and the web back around the days of Netscape 1.1.

My office is McNeil 311, which is just down the hall from the SSC Help Desk. If you have a UNIX problem, the best place to start is by doing a search on this very website, to see if the solution to your problem has already been posted. If it hasn't, please send a request for help to ssc-help@ssc.upenn.edu, as we have a lovely tracking system that makes sure that your request finds its way to me, and that you're kept up to date on your request's resolution.

If you have a more general question about UNIX, please feel free to contact me directly, either in person, by phone, or by email. I've chose to not put my email address on this website, as I don't like spam anymore than you do, but suffice it to say that it is couples@NOSPAM.ssc.NOSPAM.upenn.NOSPAM.edu :-).

Posted by ssc_upenn at 2:55 PM | Comments (0)

Some system specs

Sometimes, folks are interested in what kind of gear comprise the UNIX systems in SSC. Here is some general information about what we're doing.

We use:

Dell PowerEdge 2650 Servers
Sun StorEdge 3310 Disk Arrays
RedHat Enterprise Linux 3

Each server is differently configured with respect to CPU and RAM, although each server is a dual-CPU machine with at least 1GB of RAM installed.

The systems are monitored in real-time by the nagios utility, and the integrity of the installations is checked by tripwire.

Posted by ssc_upenn at 2:47 PM | Comments (0)