Motivation of software professionals
in [JavaScript]
|
Prev: When writing html table to div, the data from table is unformatted
Next: multi file download with one click
From: James Kanze on 17 Feb 2010 16:14 On Feb 16, 10:09 am, Nick Keighley <nick_keighley_nos...(a)hotmail.com> wrote: > On 16 Feb, 03:40, Seebs <usenet-nos...(a)seebs.net> wrote: > > On 2010-02-16, James Kanze <james.ka...(a)gmail.com> wrote: > > > On Feb 14, 4:56 pm, Seebs <usenet-nos...(a)seebs.net> wrote: > > >> On 2010-02-14, James Kanze <james.ka...(a)gmail.com> wrote: > > >> > To be really effective, design and code review requires a > > >> > physical meeting. Depending on the organization of the project, > > >> > such physical meetings are more or less difficult. > I've got mixed opinions on this. The real review takes place > off line. Explanation and discussion of possible solutions (I > know, a code walthru isn't supposed to consider solutions- a > daft idea if you ask me [1]) at a meeting. > Design meeetings can work. It's always difficult to find the right balance, because people do vary. What I think is certain is that you do need some time isolated, to let your ideas jell, and you need some meetings, at least at either end: brainstorming sessions before really starting, and code reviews after the code has been written. Between the two, different people probably have different needs. A lot of people claim that they're most effective in pair programming, for example, where as I (and some others I know) would be much less effective if I couldn't do large parts of the work more or less in isolation. -- James Kanze
From: Martin Gregorie on 17 Feb 2010 19:20 On Wed, 17 Feb 2010 13:04:17 -0800, James Kanze wrote: > On Feb 16, 3:28 am, Seebs <usenet-nos...(a)seebs.net> wrote: >> On 2010-02-16, James Kanze <james.ka...(a)gmail.com> wrote: > >> > I am. If only because such projects require a larger degree of >> > accountability than free software can offer. I can't see anyone >> > providing free software with contractual penalties for downtime; most >> > of the software I worked on in the 1990's had such penalties. > >> I think it may be done occasionally. Certainly, if I had contractual >> penalties for downtime, and my choices were Windows or Linux, I'd run >> free software. :P > > I'd use Windows XP before Linux, but frankly... I'd avoid standard PC's > completely: (modern) Solaris on a Sparc, or HP/UX on HP's PA would be my > choices. (Supposing I needed a real general purpose system. Some of > the embedded systems are probably even more reliable.) If uptime is the main criterion, your only options are fault tolerant systems. Off the shelf that means Stratus or Tandem (now HP) Guardian NonStop systems. This is the kit you find running telcos, inter-bank networks, ATM networks, etc. That apart, the most reliable system I've used is Microware's OS-9/68k, a modular real-time OS. I've been running it almost every day since 1992 and have never found a bug in the system software despite applying Y2K patches to it. I haven't replaced any hardware since 1993 either: not even disks. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Mike Schilling on 17 Feb 2010 21:01 Branimir Maksimovic wrote: > Nick Keighley wrote: >> >> I was noting the fixed point in the human experience. Things are >> degenerating and were always better in the past. >> >> <snip> > > To be honest things were always simpler in the past. Compare disks which ae formatted for a particular record size (requiring the inter-record gap to be figured into the record/track calculation) with disks that have fixed sector sizes, Which is simpler?
From: Flash Gordon on 21 Feb 2010 16:01 Richard Heathfield wrote: > Lars Enderin wrote: >> Richard Bos wrote: >>> Flash Gordon <smap(a)spam.causeway.com> wrote: >>> >>>> I know there is software flying around today that is running on Z80 >>>> processors (well, the military variant of them) and the plan in the >>>> late 90s was for it to continue for another 20 years (I don't know >>>> the details, but a customer signed off on some form of ongoing >>>> support contract). Admittedly the software I used was not doing date >>>> processing (apart from the test rigs, which used the date on >>>> printouts, which I tested to "destruction" which turned out to be >>>> 2028). >>> Single signed byte? >> >> Was it really 2028? > > Quite possibly. Not every problem ending in 8 is a 2038 problem. If the > test rigs had 1900 as a base date (and yes, there's still plenty of > software around that thinks 1900 was a very good year), then the single > signed byte Richard Bos mentioned would be good for representing all > years from then until 2027 (assuming 8 bits to the byte). It would fail > in 2028, quite possibly giving the year as 1772 instead. It was indeed 2028 when it fell over. I can't remember all of the exact details, but it was the HP Pascal system, which was based on UCSD (IIRC). I think the data structure was either defined as being 0..99 or 0..127, and it definitely hit a problem when it rolled over to 2028, but I can't remember the exact details and don't have access to the systems any more (I work for a different company). I suspect it could have been the date encoded in to a 16 bit word as 7 bits - year 4 bits - month 5 bits - day I did clearly document the date of failure when I was asked to look in to Y2K, but of course that documentation will be lost before then! I also documented that the simple work-around would be to set the date wrong and just write on the printouts the correct date! -- Flash Gordon
From: John B. Matthews on 21 Feb 2010 19:56
In article <qij857xp3j.ln2(a)news.flash-gordon.me.uk>, Flash Gordon <smap(a)spam.causeway.com> wrote: [...] > It was indeed 2028 when it fell over. I can't remember all of the > exact details, but it was the HP Pascal system, which was based on > UCSD (IIRC). I think the data structure was either defined as being > 0..99 or 0..127, and it definitely hit a problem when it rolled over > to 2028, but I can't remember the exact details and don't have access > to the systems any more (I work for a different company). > > I suspect it could have been the date encoded in to a 16 bit word as > 7 bits - year > 4 bits - month > 5 bits - day > > I did clearly document the date of failure when I was asked to look > in to Y2K, but of course that documentation will be lost before then! > I also documented that the simple work-around would be to set the > date wrong and just write on the printouts the correct date! For reference, UCDSD Pascal I.5/II.0/III.0: daterec = packed record month: 0..12; { 0 IMPLIES DATE NOT MEANINGFUL } day: 0..31; { DAY OF MONTH } year: 0..100 { 100 IS TEMP DISK FLAG } end { DATEREC } ; <http://invent.ucsd.edu/technology/cases/1995-prior/SD1991-807.shtml> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews> |