Reusing and Recycling Code
An anonymous reader sends us to a writeup about when and how to recycle code, excerpting:
"As developers, once we start separating our code into abstract ontological typologies, we make use of the human mind's phenomenal ability to work with types. Our code becomes less about jump tables and registers and more about users, email messages and images. What once was a problem of allocating resources and operations within the computer becomes an abstract, logical problem within a collection of objects....Over time, by constantly working to reuse our own code, we choose practices that work well for ourselves and discard practices that don't work as well or slow down our workflow. For developers flying solo or those working on small projects, this evolutionary process is a sufficient way of going about things. But there's trouble when we add other players into the mix--other developers, a user interface person, a database person, a sysadmin, a project mana-jerk: as a developer, they don't have access to our 'experience' of the code and we don't have access to theirs. "
If you think about how much energy is needed to produce (good) code, recycling it will also help to save the environment!
Seriously!
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
To quote from the fine article itself:
My psychic abilities tell me you're wondering why this wall of text was worth your time. It probably wasn't.
What he talks about in terms of PHP is precisely what Lisp macros are about: you identify common patterns in your code, and then you generally break the patterns into a couple of short, generic functions and a macro, or sometimes, just a macro will do.
In any other language you build a library of functions, classes, etc. to do the common things that you want to reuse.
The above applies to PHP as well. It has the include filename construct for a reason.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
This assumes the code is good. If it isn't, it's akin to eating your own vomit.
Ubisoft shows us how its done!
Ontological typologies? Am I reading a philosopohy essay here?
Part of the hardcore faithful who believed in Apple long before it was cool again to do so
A programmer who says so little in so many words is a rare sight. Promote promote promote!
A solid recommendation from an insightful article. Should be in every corporate coding guide.
What is the question in this 'story'? Is this about coding for money or free source or what?
If the question is about coding for money then it is the responsibility of the team lead/designer/architect to make sure that the business problem is divided into pieces in a way that allows different people to work in parallel (if there are multiple people on the project.)
If the question is just about some abstract idea of 'code reuse', then the answer is simple: libraries. Create libraries and document them (otherwise they are useless really, without anyone knowing what the hell is inside.)
In any case, please document the purpose of the code, and then break the higher level requirements into more granular ones with clear specifications.
In all cases divide, concur and document well seems to work best...
You can't handle the truth.
Hell is other people.
Having to work with people for whom the Peter principle has reached its end state is exasperating at best.
Then you have the emotionally unstable, the delusional, the political operators, the empire builders, the saboteurs, the goldbrickers, and of course the fearful.
Is there some reason why I would WANT to work with this motley crew of idiots, assholes, nutjobs, and losers?
Success isn't about a paycheck. Past a certain pay grade the money ceases to be a factor. I'd much rather get an adequate paycheck to work in an environment that is conducive to success than be paid generously to work someplace that sucks.
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
I fear TFA is not a joke! Unobtrusive script starts with valid markup, not garbage like this...
That (type=star) is fine if you're going to pre-process it on the server, only a moron would boast about sending markup like this to the client. If the author of this rambling bullshit article knew what he was doing, he would have used an input image type and class name of "star".
The rest of his article is similar 'junior developer above their station' type stuff. I do like the way the author of this article on code reuse makes a swipe at the concept of an "API" before going on to detail his own API (making a decorator with an Event_Manager $events property).
Being charitable, I could say TFA is incoherent nonsense. I've almost made all my charity contributions for this fiscal year, hopefully the author will keep that in mind before writing any further ludicrous articles.
That should be called "the lesson of UNIX". UNIX provided an amazing simplification that provided almost everything users and developers needed with fewer than 40 system calls (maybe half a dozen frequently used) and a single way of talking to all the objects in the computer system. People who haven't used older operating systems can't really appreciate this, but just opening and reading files used to require understanding something the size of the X11 documentation, you typically had umpteen kinds of files with half a dozen access methods each, with different calls to read blocks, fixed-size records, variable-sized records, padded and unpadded records, three varieties of carriage control, and if you wanted to read or write to a terminal or printer or card reader you had completely separate sets of calls for each. And to simplify this you had record management systems which had their own walls of documentation. And you had to understand this if all you wanted to do was to read a report from a program, because of course every programmer had learned their own bits of this and used them... so even if you didn't care about block-padded variant numbered record files with Fortran carriage control, you had to be able to deal with it. When I ported a Forth interpreter to one system, I had the whole interpreter called from a Fortran main because that let me push the whole problem off on the Fortran runtime instead of figuring it out myself.
This was worse than the line ending differences between UNIX and Windows, which are bad enough.
It's like *every* file, even plain text files, was in its own OOXML format.
Even if you only dealt with one computer and one OS.
UNIX didn't do any of that. It just made everything into a stream of bytes. For the cases where that wasn't enough, you got the whole records-oriented stuff back... in libraries. And when you used those libraries you had to deal with all the old complexity, but you only had to deal with it when you actually needed to. And lots of old timers insisted that this was backwards, that the OS was the best place to do that, so all the programs worked the same way... but the fact was that all the programs didn't work the same way, because (just as for text files) they all handled their own files and didn't handle anyone else's, and you still had to have utilities to convert data from one format to another. And you had to do it for everything.
When you're designing an API, look for simple metaphors. Look for a model where most of the time you don't need to specify any complex parameters or callbacks or helper routines. Leave a way to hook extensions in, sure, but for most software you should be able to do 80% of the things you want without having to turn to the second page of the documentation.
I'm probably going to be shouted down but in my 30 years of coding, I *rarely* reused code. Platforms change, toolchains and libraries change (glibc vs libc6), languages change, system architectures change (heavy client, client/server, n-tier, distributed) and system requirements change.
Example, a lot of what I have done over the past 10 years uses some standard navigation libraries that probably could have been 100% portable. Lat/lon to range bearing, rb2ll, etc. We've never even discussed IF it would help to make a single standard project library, even though I can absolutely tell you we will rewrite these again on the next platform.
I can't even look back on 10 years of coding and say "Oh things would have been so much better if we had shared code". I don't think that is the case. And fwiw, this is teams of 5-20 programmers on significant projects.
"there's trouble when we add other players into the mix--other developers, a user interface person, a database person, a sysadmin, a project mana-jerk: as a developer, they don't have access to our 'experience' of the code and we don't have access to theirs."
some one should read eric evans's "domain driven design" and take some notes.
Without RFTAing, I would estimate that it's 95% certain that the question behind this story is "How can I get a few thousand people to hit my ad-laden page?" And the answer is "Anonymous posting of a link to Slashdot."
.. i'm working on atm. the Team-project is trying to build an intention around what you're doing and sharing that with your peers. pretty cool concept, especially as it's integrated into the worlds best ide - eclipse.
That's quite a rant on programming for a Javascript form field validator.
The right answer to this problem was probably WebForms, which added support to HTML for basic form validation. WebForms provided for simple regular expressions in HTML forms like this one for a credit card number: />
<input type="text" pattern="[0-9]{16}" name="cc"
If the field didn't match the pattern, the browser would tell the user, in a standardized way, probably at keystroke time. The browser would also do things like prevent alpha entries in a numeric field, something that IBM green screen terminals were doing in the 1970s. (You could even program a keypunch machine to do that.) It's kind of lame that HTML forms never had any built in input validation.
For some reason, the WebForms proposal made very slow progress and never caught on.
Here is a full book about Unix written by people who have used older operating systems - Click here.
ShadowBane strode into the room, his pale Night-Elf features enveloped in the shadows of his Technomancer robes. Before him stood the artefact, an eerie light emanating from its crystal face.
He sat on the throne, in one hand brandishing a strange rune-encrusted clattering device, whilst in the other he wielded a smooth object with wheels and levers emitting a demonic red glow. His hands moved swiftly and glowing runes etched themselves on the crystal device, spelling out:
"#include <stdio.h>"
He clicked again, and the runes mystically floated upwards. The next runes were even more cryptic:
"void main(int argc, char *argv[]) { printf("Hello world"); }"
He paused, taking a sip from his recycled aluminium goblet, then taking a sheet of recycled parchment and dipping his pen into a pot of genuine organic squid ink. Out of the corner of his eye he glanced a peasant rummaging through his garbage pile. He mused about all of this, then inscribed:
"I have unlocked a mystery of great potential. By invoking the sacred word of inclusion I have unlocked a compendium, nay a veritable library of invocations and chants. Like the peasant sifting through my rubbish, so can I reuse my incantations. These shall empower me further into my research for the solution to the factorial function, a problem of seemingly infinite complexity."
``project mana-jerk''
It took me a while to understand that, until I realized he probably meant "manager". While I see the joke, I think it is insulting to managers in general. While some managers probably are jerks, I don't think insulting all of them is a good idea, and I would ask that you not do that.
Please correct me if I got my facts wrong.
I tire of people who claim that _anything_ we do helps to "save the environment". Everything we do helps to _destroy_ the environment! So long as the "saving" factor is less than 100% of the damage we produce, we have done nothing to "save the environment".
I'm sick of the "we want to have our cake and eat it too" attitude people have over these issues. The way corporations and the majority of consumers live today, almost NOBODY can claim to care about the environment. If you own anything manmade, you've directly contributed to the planet's destruction. Yes, really.
I always put these lines into About: This software is made from 100% recycled bytes, not tested on animals, does not contains cholesterol and conservants.
I am currently a database manager where I work, but that title belies the complexity of what I have to deal with on a daily basis. We are producing our "next gen" web application whilst keeping the old, but money generator up and running under the pressures of increasing user load.
Even though I am the database guy, my vast experience with software engineering has given me a "unique" role in knowing the developer's side and having a lot of input on their design decisions, as well as having huge impacts on systems.
One poster mentioned not having access to various skills and expertise in a variety of areas, and yes, there's a lot of that at my shop, so I tend to try to "bridge the gap" as it were, to help my DBA team interactt smoothly with Dev and Systems, etc.
Code reusability is a big issue in our development of the NextGen system, because the old code (that's currently pulling in the $$$$$) is not supportable, being written badly in PHP4 has resisted all attempts to upgrade. The NextGen approach uses OOP ery heavily, and also relies on stored procedures to keep the SQL out of the code and allow my DBA team to tweak and enhance performance without impacting the code base. It makes for a sweet division.
But I do find myself doing lots of talking and less actual "hands-on" development these days. Kinda crazy running around talking to various department heads, managers, project leaders, QA, and the like.
I guess I am speaking to a greater issue than code usability -- human communication to keep us all on the same page and to allow us to leverage each other's expertise. All of our efforts together represent the future success of our endeavors.
Ruby Neural Evolution of Augmenting Topologies
Developers are notorious for having a two-year attention span. Once version 1.0 is out the door, experienced coders know better than to hang around for iterations n+1. They want UP or OUT, and there's no sideways. New hires and Recent College Grads (a second level caste, at best) come in to maintain and expand a codebase that took the original developers a lifetime of experience to shape, command and release into the world. The result? Information entropy, institutional amnesia, competing visions of ultimate goals, anarchy, chaos, death marches and bankruptcy. I'm really beginning to think that the only folks who get their own paradigm right are gamers: After 10 minutes of Wind Waker or 10 hours of Metroid Prime, you've explored all there is to know about Game Cube, and it's off to Wii, where the synergies are obvious and not a single user has to be told how.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
100 comments and no one mentioned my PHB's favorite buzzword :p
"As developers, once we start separating our code into abstract ontological typologies ..."
As soon as that came out of the mouth of the prospective candidate, I'd figure that they were full of shit, and probably covering for an inability to simply sit down and crank out some good code.
My cue to stop reading was the word "ontological" and luckily I was able to stop on the very next word. A close call, no doubt, though I didn't read any of your comments either so it's hard to say.
Wow. From TFA:
:) No, seriously, I can't make out what this is supposed to mean. Who toils? Who is doing witchcraft at work? Indeed, this is a very wordy article containing very little information.
"The magicianâ(TM)s spell is our codebase, and as they toil in their laboratories collecting newts and dragon finger-nails, so we assemble libraries or components and frameworks."
Yeah, that's what I do at work all day.
Lord Byron II shows us how its done!
quia potentia mens mentis
ontological, evolutionary, reuse. Yup, stick to MS Project and let us do work.
Will you come up with a one-off method of assassination, or will you create a nice set of assassination instructions that can be reused?
Or will you clime the scale and come up with some philosophical framework to best keep idiots from doing jobs they aren't qualified to do?
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
They absolutely ruined Myst IV. By insisting that users have graphics card capabilities that are NOWHERE needed for that game, they cut their own potential market by probably around 80%, and the game will not play on a lot of machines it is advertised to run on. I can do without game companies that display that kind of stupidity. I spoke with a programmer at Cyan -- the actual maker of the game -- who told me that as far as he was concerned, Ubi (the distributor) had taken an excellent product (as the Myst games historically were) and stomped all over it.
I strongly suggest he read a few (5 or 6 year-old) books on Agile programming techniques, and maybe start working in a modern language like Ruby.
Do not misunderstand! I do not dispute much of what he writes. The problem is: what he writes about are old problems that have already been addressed by others. Maybe he should spend a bit of time studying what others in the industry are doing/have done, before wasting his time writing what others have already written, and better. Far better.
If you want to be a cutting-edge programmer (which is what you had better be if you are writing about how others should write their programs), I think it behooves the writer to be more-or-less up-to-date on the subject himself.
Precision is important.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Yeh, I've talked to some of the people who wrote that book. You know that bit I wrote about having to understand how a database engine works to open a text file? That's exactly the kind of thing they're unhappy about losing. Oh yeh, lots of misplaced nostalgia about the DECsystem, which I used and found at best lesser evil than IBM... it was still full of the same kinds of needless complexity and internal incompatibility.
If you'd like to be able to be an effective leader even in situations where you're clearly the best, but you feel the need to have some push-back in order to do that - why not try second-guessing yourself? Surely you've programmed something single-handedly at some point - were you able to be an effective one-man "team" even though you had no equals? Of course, because you come up with a plan and then think it over, look for holes, better approaches, etc - and can usually give your first attempts a run for their money.
If you treat those with less skill, experience, or talent than you badly; not only do you create a poor working environment, you also pass up to opportunity to benefit from the things they may be better at than you.
A good team leader should inspire, not annoy. And if you're the top banana and you find your team annoying you, make sure you've let them know before hand that you feel personally responsible for the end result of *everyone's* work. They'll be more likely to cut you some slack if you seemed stressed by their short-comings - if they remember it's mostly your butt on the line if they screw up.
You sound like you're satisfied with your current situation - I only offer this advice in case you'd like to try having the same level of success in any team make-up, and without being perceived as a jerk by your co-workers.
On code reuse.. a flexible driver.
From the Book Linux Kernel Dev.
more or less..
"provide mechanism, not policy"
The policy is WHAT (data) they want and WHEN (time/event).
The mechanism is the HOW (language, libraries, ADT's, Architecture(eg. I'm going to use a generic container class, or No1 I'll use an array..or no1 I'll use pointers to my managed memory, and a huge private library of home-brewed accessor methods).
Of course the WHAT will change before you can say "blue berry pie". Will that derail your HOW..? eh?
How much the WHAT is affecting the HOW?
A new/changed requirement is a one-two liner change with simple steps to rebuild and re-test or a nightmare of side effects and gotcha's. Eh?
How cleverly you do the HOW will determine whether you are writing throw away code or the killer module that will spread like fire through your company/web.
- these are not the droids you are looking for -