No they don't, code review and design walkthroughs are the best tools I know for those.
-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
Viewing a computer program as though it is a complex machine of several interacting components, it can take several days for any one person to become familiar with it (and a program can be of a size several orders of magnitude more complex than most mechanical marvels)
This is where reviews and walkthroughs fall down, because the reviewers have complex machines of their own to husband and cannot pay much more than scan attention to the programs under inspection.
Sounds like it's time to pay a little more attention to the KISS principle. (I realize that large corporations might want to burn me at the stake for this heresy...)
-- /~\ Charlie Gibbs | They don't understand Microsoft \ / | has stolen their car and parked X I'm really at ac.dekanfrus | a taxi in their driveway. / \ if you read it the right way. | -- Mayayana
Indeed, and very often the way to achieve that is to break the design into modules with rigidly defined interfaces while roughly grouping them by function. It goes without saying that there is almost certainly some sort of module hierarchy, but its depth needs to be kept as shallow as possible.
This approach simplifies design reviews, makes design validation a lot easier and also makes costing the project simpler.
It also simplifies the code and module test phase because, if the design documents are any good, writing test harnesses and specifying module test suites becomes straight forward and also lets you catch bugs well before they become horridly apparent during integration testing, let alone, as I've seen, when they surface, inexcusably late, during acceptance or performance testing.
Ideally, the test harnesses and scripts will be kept under version control - just like the production code - because they will be extremely useful later for regression testing as and when requirements change and the code gets modified to suit.
And, before you ask, I've worked on projects that were designed and implemented using exactly this strategy:
- On one large project that had a very complex data model that needed its database to be populated before the system was remotely useful. This approach let us use an incremental release strategy, i.e. the system initially went live with the online system's navigation and help subsystems complete, but with with only the screens and reports needed for the users to create the two catalogues that everything else depended on. Other functions were build and put live after the main catalogues were complete enough to be useful.
This wasn't a financial or manufacturing system: the underlying data structure was a lot more complex than those generally need because it had to track 'products' from initial concept through design, production, use and partial reuse so those involved could be paid for the use and reuse of their individual contributions.
- a large consultancy I worked for used exactly those design principles to cost projects we were bidding on: the project manager, application and database designers were all on the bid team from the start and had a large hand in costing what they would deliver if we got the contract.
-- Martin | martin at Gregorie | gregorie dot org
Yes, yes and thrice yes!
Initially yes and if you're building a single program - but if you're building a toolkit on which to base applications then once you have the fundamentals down solid it is time to build higher level constructs guided by emerging common themes in the applications being built. Do not do this prematurely!
I once got to do this for seven years straight (we called it sedimentary programming and put down a lot of really well defined layers) - by the time we'd finished that toolkit was like a well stocked magicians staff, nearly everything at the application level had become declarative, the source still fitted on a floppy and the range of applications had expanded vastly over the original conception.
At one point we came across a performance bottleneck and tracked it down to the oldest, lowest level of the stack - because everything had well defined APIs and comprehensive unit tests I was able to completely rewrite that bottom layer to eliminate the bottleneck and once I had it passing all the tests the only effect of releasing it was to greatly improve the performance and scalability - no other code broke or needed changing despite there being several years of layering by then.
The project was shut down because it was found by highest management to be in the hands of "men with ponytails" and that was unacceptable so an IBM Websphere replacement was commissioned and anything it couldn't do was deemed undesirable. I moved on of course.
You can even go one further and write the module tests independently of the code based solely on the design documents, it is amazing how well this picks up hidden assumptions in the design document as implementer and tester interpret it differently. IME the spirit of friendly competition it inspires leads to really good tests that probe edge cases as well as the obvious and really solid code because the implementer knows what the tester is up to.
There's always the ones reserved for the customer to find.
Of course.
-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
I thought doing that would be the obvious approach, so didn't spell it out. Mea culpa.
Nowadays, and using Java (or any other language with an equivalent development tool to javadoc), I'd go further and say that the module specification should be compilable: in Java terms it would contain all publicly declared constants, constructors and methods, each preceded by a comment describing the purpose of the item and how it should be used.
Since its quick to do, these specifications must clean compile before the designer signs them off.
:-{
But if the unit test scripts, which ideally should be specified BEFORE any code is written, are reasonably well thought out, then there should not be a lot for the customer to find.
-- -- Martin | martin at Gregorie | gregorie dot org
There is a widespread convention that code and tests must be written together by the same person - test driven development done wrong.
-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
Having worked in two safety-critical areas, railway brakes and saloon car power steering that comment is not made in fun :-(
Total agreement that the 'widespread convention' is utterly, stupidly wrong.
Module and system tests should be written by the designer and acceptance tests should be written by whoever signed off the system specs on the user side.
-- -- Martin | martin at Gregorie | gregorie dot org
Slightly better if they're written by another developer who only gets to see the design docs and not the code. This tends to expose places where the design document has ambiguities.
Yep - you should have heard the howls the one and only time I saw this insisted upon. After the first misunderstanding was found the prime howler became the staunchest defender of the principle and ran the most draconian acceptance tests I've ever seen.
-- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
Fair comment
Reminds me of the time when I was acceptance test manager for an experimental[*] secure interbank network we'd developed for Austrian outfit that provided ATM and interbank comms for their banks. It ran on Stratus fault-tolerant kit that had been shipped to us develop the system on. The Austrians had done a super job writing acceptance tests and an equally good one setting up comms when they got the Stratus it back: it had to handle encrypted messages using X.25, DECnet, and IBM SNA (LU.2 and LU6) protocols.
Anyway, acceptance testing started with us mainly sitting round twiddling thumbs, but what we couldn't understand was why the acceptance test crew's faces got longer and longer as the days went by. Then after several days big grins appeared and a happy cry of "We found a bug!" was heard. It turned out that the long faces were because the acceptance team hadn't found any problems and thought they weren't doing thorough enough testing.
[*] experimental, because there was ongoing discussion among the banks about exactly what traffic they wanted the interbank network to carry, so we'd been asked to create a secure, fault tolerant multiprotocol switch to carry user-defined messages. After 2-3 years they'd decided what the national switch neeeded to do and came back to us the write it. Can't recall what I was doing at that point, but I wasn't on that project. Pity, because I liked the gang we were dealing with and enjoyed my time in Vienna.-- -- Martin | martin at Gregorie | gregorie dot org
Or omissions. I was once given a set of specs so detailed I could almost have written a compiler for them. But it didn't cover all cases. I asked what I should do if X happened, and got the answer which is now at the top of my list of Famous Last Words: "Oh, don't worry about that; it'll never happen." By this time I had enough experience to realize that "never" is usually about six months, and got really hard-nosed about having everything covered by the specs.
-- /~\ Charlie Gibbs | They don't understand Microsoft \ / | has stolen their car and parked X I'm really at ac.dekanfrus | a taxi in their driveway. / \ if you read it the right way. | -- Mayayana
might have to experiment a bit with TERM/term. SHould work. Check any compat settings in the menu.
You could also install a different xterm-like application and run THAT one. Or, my favorite, run lxterminal as a DIFFERENT user, and keep those settings separate from the normal ones. (how to do that, think of it as an exercise in "know Linux")
-- (aka 'Bombastic Bob' in case you wondered) 'Feeling with my fingers, and thinking with my brain' - me 'your story is so touching, but it sounds just like a lie' "Straighten up and fly right"
For modern purposes you really shouldn't be using telnet. You can enable vt100 emulation mode in most ssh software - for instance putty offers vt100 compatibility mode in the "settings" panel. kterm also offers vt100 mode via a command flag iirc.
I'm pretty sure that's widespread knowledge by now...has been for probabbly at least 20 years. That said, there are plenty of devices out there that don't support ssh: old 8-bit computers serving up a BBS through an ESP8266 on the serial port, not-so-old managed network equipment (I have a bunch of older Cisco gear at work that doesn't speak ssh), etc. As long as you're aware of the security implications and take steps to mitigate what you can (those switches at work can't be accessed from outside our network, for instance), the world isn't going to end if you telnet in to something.
_/_ / v \ Scott Alfter (remove the obvious to send mail) (IIGS(
The ESP could handle the SSH and just send/receive terminal traffic on the serial port ... I don't know if puTTY's ANSI emulation is as good as telix/procomm?
On 18 Oct 2021 at 01:41a, Scott Alfter pondered and said... SA> I'm pretty sure that's widespread knowledge by now...has been for SA> probabbly at least 20 years. That said, there are plenty of devices out SA> there that don't support ssh: old 8-bit computers serving up a BBS SA> through an ESP8266 on the serial port, not-so-old managed network
[snip]SA> accessed from outside our network, for instance), the world isn't going SA> to end if you telnet in to something. SA> SA> _/_ SA> / v \ Scott Alfter (remove the obvious to send mail) SA> (IIGS(
Nice signature BTW
Agree, there are still BBS running telnet around the globe but also offering SSH too.
I'm typing this reply from one now :)
It's one thing having old telnet servers when they are the only remote shell supported on legacy devices, it's quite another to enable a telnet server on a modern system when you should be sshd.
---druck
Leave them on the side of the plate and stop complaining.
-- Steve O'Hara-Smith Odds and Ends at http://www.sohara.org/
Not for actual communication, no. But as a quick and dirty means of checking for a running server, and usually seeing the server's banner, it's difficult to beat. I've also been known to test SMTP servers that way.
And do they use the same commands as the telnet client? The ones I've been using for decades?
-- Joe
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.