Thursday, December 20, 2007

2008 Web Projects

Givens:

  1. Incremental changes to move from image-heavy to css-compliant design

  2. Build web training app for CT??



Ideas:

  1. improve User Interface for ACE (registration.techtransfer.berkeley.edu)

    1. phone-interview ACE registrants

    2. in-house?

    3. hire a contractor?

    4. virtual company?

      1. Find a mentor

      2. Find experts

      3. do the whole project management thing



    5. bug/pay vendor to clean up their code?



  2. ditto for Squirrelcart:

    1. phone-interview borrowers

    2. in-house?

    3. hire a contractor?

    4. virtual company?

    5. bug/pay vendor to clean up their code?



  3. build a meta-search app that returns results from ACE, Clearinghouse, Video catalog, etc.

Labels: ,

Tuesday, December 18, 2007

Ok, I just removed that link.
Thanks,
Daniel

Helen Bassham wrote:
Dear Daniel & Steve - please, can we remove the link to the Intro to ITS Architecture Scholarship Program from our web site on on-line training?

http://www.techtransfer.berkeley.edu/web-based-training/

We are no longer offering this scholarship.

Labels:

Monday, December 17, 2007

Fixed 404s

Besides the usual hax0r crud, I found and fixed these 404 errors:
/distancelearning/: symlink -> web-based-training
/helpdesk/: symlink -> services home page
(Hmmm... should I put in redirects instead?)

Labels: , ,

Competitive Analysis

Oregon T2 Center
Features:

T2 Lending Library

  • Catalogs: PDF downloads (no web search form)
    • Publications
    • Video/DVD

    By Subject:
    • Bridges
    • Concrete
    • Environmental
    • Equipment
    • General Information
    • Legal
    • Roadway - Construction
    • Roadway - Drainage
    • Roadway - Paving
    • Roadway - Safety
    • Roadway Maintenance
    • Trenching/Confined Space
    • Winter
    • Workers Safety
    • Workforce Development

Quarterly Newsletter

  • PDF download only, no HTML
  • Nice feature: What's wrong with this picture?
  • Legislative update
Cosponsors classes with APWA

Monday, December 10, 2007

Dream Programs

Chess kibbitzer: for every move, kibbitzer cites master games that had the same board layout. E.g.: 1.Nf3 "Ah yes, the Reti. One of the most flexible opening moves." Teaching: link to the complete master game. Big ol' database of board positions from master games. ? How to match functionally equivalent differences?

Labels: ,

Subversion User Best Practices

Policy

We use an Unstable Trunk policy.
  • Most development happens in the trunk (Live web site).
  • Don't break the trunk!
  • Bugs are found - by our users if we miss them! - and fixed quickly.
Alternative: do work on a branch, and later merge changes.
  • Means more merging.
    • A lot more merging.
  • Easier to ignore what other developers are doing :-(
  • Always-Branch policy typically used in a heavily centralized situation where a supervisor OKs each coder's work (branch) before it is merged.
I think we might branch if we were going to change the whole site, e.g. PHP->Java, or a fundamental change to the way we INCLUDE navbars etc.

Commits

  • Commits are good; commit each discrete thing you do. "Commit as soon as your changes makes a logical unit. ... To make it simple: your SVN comments shouldn’t explain that you did more than one thing. If your SVN comment looks like “Fixing bugs #1234 and #1235″ or “Fixing bug #4321 and correcting typo in debug string” then you should’ve used two commits." - Salvatore Iovene (http://www.iovene.com/5-svn-best-practices/)
  • Don't commit to "save your work" at the end of the day.


Comments

Any communication tool becomes useless if you send garbage through it.
So you need to make sure that people can understand your changes.
  • Each change should be self-contained.
  • The log message should contain useful information.

    • What did you change.
    • Why did you change it.
    • Include filenames touched and functions modified.
    • Make it possible to grep the logs later when looking for something.

Labels: ,

Friday, December 07, 2007

Subversion admin

Notes about our needs:

We are a small group. (2 main programmers, occasional help from ~3 others. ~3 managers who occasionally request changes or additions to content.)

Our project is a web site. We are mostly using svn:
  • to back up our work
  • to document changes we make (communication/collaboration)
  • for the security of being able to roll back changes that don't work out

SVN best practice is to:
  • keep working files in a URL like repository/trunk (will do)
  • keep parallel efforts in repository/branches (The only time we would have parallel efforts is in the case of a long, drawn-out redesign. We intend never to do that again, rather just incrementally evolve.)
  • keep "snapshots" in repository/tags (yeah, maybe)


1. Create a repository:

[steve@www steve]$ svnadmin create myrepository
[steve@www steve]$ ls -lp myrepository/
total 28
drwxr-xr-x 2 steve web 4096 Dec 7 15:19 conf/
drwxr-xr-x 2 steve web 4096 Dec 7 15:19 dav/
drwxr-sr-x 5 steve web 4096 Dec 7 15:19 db/
-r--r--r-- 1 steve web 2 Dec 7 15:19 format
drwxr-xr-x 2 steve web 4096 Dec 7 15:19 hooks/
drwxr-xr-x 2 steve web 4096 Dec 7 15:19 locks/
-rw-r--r-- 1 steve web 229 Dec 7 15:19 README.txt
[steve@www steve]$ svn mkdir file:///home/steve/myrepository/tags -m 'create steve/myrepository/tags/'

Committed revision 1.
[steve@www steve]$ svn mkdir file:///home/steve/myrepository/branches -m 'create steve/myrepository/branches/'

Committed revision 2.
[steve@www steve]$ svn mkdir file:///home/steve/myrepository/trunk -m 'create steve/myrepository/trunk/'

Committed revision 3.
[steve@www steve]$ ls -lp myrepository/
total 28
drwxr-xr-x 2 steve web 4096 Dec 7 15:19 conf/
drwxr-xr-x 2 steve web 4096 Dec 7 15:19 dav/
drwxr-sr-x 5 steve web 4096 Dec 7 15:20 db/
-r--r--r-- 1 steve web 2 Dec 7 15:19 format
drwxr-xr-x 2 steve web 4096 Dec 7 15:19 hooks/
drwxr-xr-x 2 steve web 4096 Dec 7 15:19 locks/
-rw-r--r-- 1 steve web 229 Dec 7 15:19 README.txt

Huh? No changes? Oh wait...

[steve@www steve]$ svn list file:///home/steve/myrepository
branches/
tags/
trunk/


2. Add a project:

[steve@www steve]$ svn mkdir file:///home/steve/myrepository/trunk/htdocs -m 'create htdocs project'

Committed revision 4.
[steve@www steve]$ svn import css file:///home/steve/myrepository/trunk/htdocs -m 'import css/'
Adding css/ttStyles.css
Adding css/tt_squirrel.css
Adding css/media.css
Adding css/oldSite.css

Committed revision 5.

[steve@www steve]$ svn list file:///home/steve/myrepository/trunk/
htdocs/
[steve@www steve]$ svn list file:///home/steve/myrepository/trunk/htdocs
media.css
oldSite.css
ttStyles.css
tt_squirrel.css

Note that what I probably intended was to make a css folder in the htdocs project in myrepository...

When is Sorted Not Sorted?

Recently used BBedit to grep out good addresses from a mixed list of addresses using "Tools->Process Lines Containing..." with Grep expression.

Then used the Calmail web form to upload the list.

Used Calmail web form to show the list.

Copied the list from Mailman web page, pasted into a new BBedit file and compared it to my source file using bash diff. Big problem - many many differences that look the same to me!

Noticed that Mailman had converted all the emails to lower case. Used BBedit "Text->Change Case..." to do the same to my source list. Ran bash diff again. Still many many differences that look like....sort-order differences!

Ran sort on both files.

Now the problem is that 179 addresses apparently failed to upload!

Running sort -u finally cleared up all differences. Mailman silently de-duped the source list.

Moral of the story: assume that different apps (BBedit, Mailman, sort) will use different sort algorithms with different resulting sort orders.

2nd moral: I would have saved time and aggravation by doing all my editing in one environment.

Wednesday, December 05, 2007

Mailing list maintenance

On Monday, December 3, 2007, Information Services and Technology (IST) migrated all existing Majordomo and Simple mailing lists to the mailing list manager Mailman.

This affects the 16 lists we moved to campus Majordomo earlier this year.

I made configuration changes today:

  1. Administrivia: No

    If enabled, Administrivia handles postings that appear to be requests to be added to or deleted from the list by redirecting them to the list administrator only, not to the list.

    For the registrar mailing list, this was big trouble, since it's a list FROM the general public TO a set of account representatives, and frequently the message is "Add me to your mailing list," or "Cancel my registration for class X."

  2. Max days to hold: 0

    Default is 14 (days, or two weeks). 0 to hold forever.

  3. Forwarding of Admin messages:

    All messages to the list owner-administrator (ttplists@berkeley.edu) are being forwarded to me (w3steve@berkeley.edu). Not affected by the move to Mailman.



Turns out there is another admin account for another three mailing lists. techtransfernews@berkeley.edu owns


  • railconference@lists.berkeley.edu

  • techtransfernews@lists.berkeley.edu

  • ttp_instructors@lists.berkeley.edu



These are Us-to-the-World lists. Only techtransfernews@lists.berkeley.edu is used now. The others are managed from ACE, I think. (Why don't we use ACE for techtransfernews?)