Wow I also have been working on embedded ARM and Linux for the last two years (and just 'normal' server-side Linux before that, since the minix release), and I was just about to post the same basic points until I read yours... uncanny.
With regards to linux and fixed-purpose computing (embedded is a bit cliche a word, these days...) I would say that the one thing to always remember is that it ain't running until you've built some hardware...;)
what I am saying is that if it really matters how you do something, it's usually a requirement or a constraint
Sorry, but you are really missing my point, I think because you are trying to make a counter one.
It doesn't matter 'how' you're doing something in any other way but that the customer understands why it is you're doing it, 'how' you're doing it. This is what the Design is supposed to do - propel the requirements into the physical world, and provide the -mechanics- for the theoretical thing you are going to do (as defined by the requirements).
Design does not mean only 'minor details of the colour of a button'. It means, this is the thing we are building and we are building it this way. Req's for sure are important, but if the customer has no idea, or is querying the process (as this article is about), then it demonstrates that a proper design, and more importantly review with the customer for requirements proofing has not been done, or not been done properly...
It's not really something many people are interested in or need to know how to do.
Isn't it?
On that subject I think the more interesting thing is that teaching some 'newbie' the beauty of programming, breaking a technocratic elitist programmer taboo is something not many people are interested in... or know how to do.
C is such an easy language to learn now, that I have seen folks pick it up in a week and put it to use.
Set her up with some SDL libs (Game Kit) and a couple simple makefiles, show her how to type 'make' and run the program, and away you go.
Honestly. C is a good language for anyone to learn. I don't think its right to treat languages as 'especially hard' or 'especially easy', though, for different 'classes' of people... so maybe this recommendation may not go down to well...
i dunno... i think i agree with you, on the basis that probably, 3com is being run strictly on a 'line-item value' basis, having imbued huge investment as a spike in the dot-com promotion mill... but on the other hand, i have to wonder if 3com, progenitors of one of the most widely respected networking hardware add on hasn't just had its day.
so i'm forced to just 'meh..' you in reply. i think you're way ahead of 3com. the accountants are running the show, and who knows just how valuable open source code really is?
The problem is that this requires putting a lot of mass into space, and then dragging that mass around wherever you go.
okay, with regards to the former, i believe we could put a hell of a lot more water into LEO if we just tried (hell, make it a line-item for future World Bank Loans, or some such ficken thing...), and on th elatter, once you push, its no longer a shove. as long as its in the direction you want to go...
personally, in a few years time, if there is a 'water is key to space epxloration' eureka moment, i'm gonna take personal satisfcation for having called it... on/.
We've now reached the point where the discussion turns to semantics, so it would probably be best if we agreed to disagree.
Actually, no. I really mean what I mean: when the customer describes for you what they want, this is requirements.
When you tell them how it is you are going to accomplish their wishes, and 'why you are going to do it the way you do', this is Design.
If there is no distinct difference between the two states in a project life cycle, in my 25 year experience, the project fails.
Simple as that. We may have, between you and me, whatever communication problems/. may afford, but when it comes to letting the customer know what it is you will be doing for them, as a service, Requirements comes first, then Design...
what i never understood is why NASA doesn't focus on super-structure construction... say a spheroid structure of some geometric order... which is then filled with water, which then has the crew module inside, which is incidentally designed for self-enclosed, sufficient, sustained surrounded-by-water living... something we can develop fairly well down here.
in other words, all this effort to make a spacecraft, when in fact we need to a) blow a very big bubble of water, b) put crew in it, c) shove it off in the right direction.
i guess the idea of having an extreme mass of water in orbit is a bit far-fetched, but it always seems weird to me that we're not really pushing our materials-science stuff to be 'lazy' in the right places. humans need water, why don't we just learn to live in the 'water tank' down here, then put it up there and do the same thing...
well, the relevance, however farfetched, is that water seems to provide a good protection from harmful elements, right? put the electrostatic shields around the massive water sphere, and a yellow submarine or two in the middle, and nudge it on its tumble-weed way to mars...
He's talking about the interface, the arrangement of information into pages, the functionality provided by the site - not the design- and implementation-level differences of whether this functionality is provided using static pages, PHP, JSP, or whatever.
This is design, not requirements. "How" the functionality they require will be implemented, is design.
By that first line it sounds as if Doom 1 was REVOLUTIONARY (and it was to be honest).
Yeah. I distinctly remember there being other multiplayer deathmatch games around at that time... such as SpectreVR, for example...
DOOM was a great game, for sure, but it was more an evolutionary step, which everyone wanted and had a demand for, than it was a Revolutionary jump. What made DOOM 'special' in those days was that it was legal and expected that you could download it and copy it with your friends; in those days, Shareware Floppies was all the Internet a lot of people had...
No, I mean Design. Requirements is an important step, for sure - but it is the customer who defines this, mostly, so I am assuming that his customer knows this already.
If, this far into the development of the project, the customer feels that there are faults with the -technical design- of the project, or does not understand enough of the "Why" of the design and consequently queries the developer on comparison with some other site, then in my opinion it means that an "ol-skool" programmer tool, namely "Design Review with the Customer" has not been done.
Before you write a line of code, you should have a clear plan of attack for the technologies you're going to use, how you're going to use them, and why.
This should be pretty clear, from the beginning, both with the developer and the client... why?
Because it is at this phase of things, when reviewing the gameplan and overall 'design' of the work to be done, that the client has a chance to refine their requirements - often, new business logic can be explored, the customer might have a 'eureka!' business process moment upon enlightenment about how computers work, and they can even prepare for such business logic in other parts of their organization. This is a valuable step, and comes from an objective review of a new software project design with the developer, in the middle ground between business logic/requirements and raw code technology.
Don't let the 90's Dilbertification of modern business process deter you from having meetings. Meetings, done properly and with explicit policy on how to conduct them and why, are very effective.
It seems to me that the posters problem at this stage, is simply because they didn't have a meeting to review the design and overall gameplan for implementing the customers requirements, before they got started... and now the client is confused, doesn't have a 'feeling' for whats going on, and is so far disconnected from the project that they're going to competitor sites and casting allusions on those winds...
Sure but its friggin stupid, you think you can fire a ball at high speed ? BULLSHIT, in a word, you every try to fire a paintball at > 500 fps ? 70 % of the time it just disentegrates in the barrel.
Umm... re-read that, dude. I didn't mention speed, anywhere, in reference to control.
I could dial the cyber9k waaay down and it would 'softly' curve the ball... I got in more trouble on the field doing that, than I did for over-taco'ing...
i'll be the military could use electro-pneumatics and range-finding, if they had to... or hell, yeah... even just a few cheap Tippmans could work, i'll bet.
In my opinion, this points to a decided lack of a proper design phase in you development process.
Does the client really not know enough about the design of what you are building for them, that they have made such an 'obvious' mis-comparison with the other project?
Design is more than just 'its going to work this way', its also 'its going to work this way, because'...
bitchslap: "pfft. you clearly know -nothing- about paintball guns."
a good paintball gun will let you dial in whatever you want, and get the ball there. put an army-style range-finder on an electropneumatic, fill its hopper/feeder full of gummy-PIC's, fill the tank, charge the battery, calibrate, and you've got fieldable ball-placement in whatever nook and cranny you engender to explore...
*sigh* i loved my cyber 9000, the few times it worked. i'm sure those guys have moved on to far better stuff...
One thing that you have to take into consideration is that Sharp probably doesn't expect to sell a whole lot of these things... its fair to say that their treatment of the Zaurus product line (I have an SL-5500, love it to death...) is pretty much an afterthought, for the consumer market.
Instead, you'll see these things being used a lot by sytems integrators for business/commerce systems, and that explains the average higher cost for the Zaurus PDA's over other, equivalently featured products from competitors.
That said, the Zaurus is a whole lotta computer for what you pay and pretty much smokes the competition when it comes to programmability. When was the last time you spent a few hours tweaking the PalmOS kernel to exact every last bit of performance out of it? Well, that happens all the time in Zaurus land, and there are a really amazing wide range of options for this PDA, when it comes to distro's...
Look for OpenEmbedded-based distro's in the future lineup of linux-based PDA's. It really is smooth and sexy... I've been with PalmOS since day one, but this year I abandoned it completely and moved exclusively to Linux for my pocket computing needs... and let me just say that it is tres-exciting, ssh'ing over WLAN to the bulge in my pocket where I've got bittorrent's sitting alive for the local 2600 meeting, ooh yeah...
How about a story about the video projector I built out of a Reflecta 35mm slide projector and a Sega GameGear in the early '90
Actually yeah, I would be quite interested in hearing about that, since I am of the ilk that whatever physical endeavours a man chooses to waste his time on, its still a lot more interesting than hearing someone shit all over someone else, just because "it doesn't excite them"...
So tell me how you made a video projector. If its cheap, I might yet still learn something from you, even though you aren't being 'innovative'.
ummm... its since been pointed out to me that my bookmark for "The Camera Van" has been borked/hijacked by a spycam outfit... the site I was referring to is this one...
Half analogue, half digital? He's just scanning a large negative, hardly earth shattering.
What is with this freaking diminutive attitude? Is your life so shallow and meaningless that you can't see any beauty in the effort it took to set this up, from a geek angle?
Honestly, this is one hell of a cool project. So its not portable, so what? Its still some interesting science, well applied, to a real-life situation with good result.
The neg size is quite puny really. At Antwerpen Photograpic Museum I saw a camera which was HUGE - as tall as me. Took something like 4 foot negative plates.
Slashdot Mirror
I mean really. I haven't used a CD in 2 years.
...
If it ain't on the 'net, it ain't something I'm interested in
Wow I also have been working on embedded ARM and Linux for the last two years (and just 'normal' server-side Linux before that, since the minix release), and I was just about to post the same basic points until I read yours... uncanny.
... ;)
With regards to linux and fixed-purpose computing (embedded is a bit cliche a word, these days...) I would say that the one thing to always remember is that it ain't running until you've built some hardware
Blackberries may be popular in the United States, but in the rest of the world everyone has moved on ... to smart phones.
Of course, the convergence from PDA to phone and back again is not without its detractors...
what I am saying is that if it really matters how you do something, it's usually a requirement or a constraint
...
Sorry, but you are really missing my point, I think because you are trying to make a counter one.
It doesn't matter 'how' you're doing something in any other way but that the customer understands why it is you're doing it, 'how' you're doing it. This is what the Design is supposed to do - propel the requirements into the physical world, and provide the -mechanics- for the theoretical thing you are going to do (as defined by the requirements).
Design does not mean only 'minor details of the colour of a button'. It means, this is the thing we are building and we are building it this way. Req's for sure are important, but if the customer has no idea, or is querying the process (as this article is about), then it demonstrates that a proper design, and more importantly review with the customer for requirements proofing has not been done, or not been done properly
It's not really something many people are interested in or need to know how to do.
Isn't it?
On that subject I think the more interesting thing is that teaching some 'newbie' the beauty of programming, breaking a technocratic elitist programmer taboo is something not many people are interested in... or know how to do.
C is such an easy language to learn now, that I have seen folks pick it up in a week and put it to use.
Set her up with some SDL libs (Game Kit) and a couple simple makefiles, show her how to type 'make' and run the program, and away you go.
Honestly. C is a good language for anyone to learn. I don't think its right to treat languages as 'especially hard' or 'especially easy', though, for different 'classes' of people
i dunno... i think i agree with you, on the basis that probably, 3com is being run strictly on a 'line-item value' basis, having imbued huge investment as a spike in the dot-com promotion mill ... but on the other hand, i have to wonder if 3com, progenitors of one of the most widely respected networking hardware add on hasn't just had its day.
so i'm forced to just 'meh..' you in reply. i think you're way ahead of 3com. the accountants are running the show, and who knows just how valuable open source code really is?
backups. enough said.
The problem is that this requires putting a lot of mass into space, and then dragging that mass around wherever you go.
...
... on /.
okay, with regards to the former, i believe we could put a hell of a lot more water into LEO if we just tried (hell, make it a line-item for future World Bank Loans, or some such ficken thing...), and on th elatter, once you push, its no longer a shove. as long as its in the direction you want to go
personally, in a few years time, if there is a 'water is key to space epxloration' eureka moment, i'm gonna take personal satisfcation for having called it
We've now reached the point where the discussion turns to semantics, so it would probably be best if we agreed to disagree.
/. may afford, but when it comes to letting the customer know what it is you will be doing for them, as a service, Requirements comes first, then Design ...
Actually, no. I really mean what I mean: when the customer describes for you what they want, this is requirements.
When you tell them how it is you are going to accomplish their wishes, and 'why you are going to do it the way you do', this is Design.
If there is no distinct difference between the two states in a project life cycle, in my 25 year experience, the project fails.
Simple as that. We may have, between you and me, whatever communication problems
what i never understood is why NASA doesn't focus on super-structure construction ... say a spheroid structure of some geometric order ... which is then filled with water, which then has the crew module inside, which is incidentally designed for self-enclosed, sufficient, sustained surrounded-by-water living ... something we can develop fairly well down here.
...
...
in other words, all this effort to make a spacecraft, when in fact we need to a) blow a very big bubble of water, b) put crew in it, c) shove it off in the right direction.
i guess the idea of having an extreme mass of water in orbit is a bit far-fetched, but it always seems weird to me that we're not really pushing our materials-science stuff to be 'lazy' in the right places. humans need water, why don't we just learn to live in the 'water tank' down here, then put it up there and do the same thing
well, the relevance, however farfetched, is that water seems to provide a good protection from harmful elements, right? put the electrostatic shields around the massive water sphere, and a yellow submarine or two in the middle, and nudge it on its tumble-weed way to mars
all of them, mixed up in a horrid hijack of the device, into pure fetid pungence, reminding you of a gaping open wound ...
True.
But recording has also meant a lot of people can make their own tunes...
Roll your own...
He's talking about the interface, the arrangement of information into pages, the functionality provided by the site - not the design- and implementation-level differences of whether this functionality is provided using static pages, PHP, JSP, or whatever.
This is design, not requirements. "How" the functionality they require will be implemented, is design.
Before DOOM, there was Spectre VR, which was all about multiplayer gaming...
By that first line it sounds as if Doom 1 was REVOLUTIONARY (and it was to be honest).
...
...
Yeah. I distinctly remember there being other multiplayer deathmatch games around at that time... such as SpectreVR, for example
DOOM was a great game, for sure, but it was more an evolutionary step, which everyone wanted and had a demand for, than it was a Revolutionary jump. What made DOOM 'special' in those days was that it was legal and expected that you could download it and copy it with your friends; in those days, Shareware Floppies was all the Internet a lot of people had
No, I mean Design. Requirements is an important step, for sure - but it is the customer who defines this, mostly, so I am assuming that his customer knows this already.
... why?
... and now the client is confused, doesn't have a 'feeling' for whats going on, and is so far disconnected from the project that they're going to competitor sites and casting allusions on those winds ...
If, this far into the development of the project, the customer feels that there are faults with the -technical design- of the project, or does not understand enough of the "Why" of the design and consequently queries the developer on comparison with some other site, then in my opinion it means that an "ol-skool" programmer tool, namely "Design Review with the Customer" has not been done.
Before you write a line of code, you should have a clear plan of attack for the technologies you're going to use, how you're going to use them, and why.
This should be pretty clear, from the beginning, both with the developer and the client
Because it is at this phase of things, when reviewing the gameplan and overall 'design' of the work to be done, that the client has a chance to refine their requirements - often, new business logic can be explored, the customer might have a 'eureka!' business process moment upon enlightenment about how computers work, and they can even prepare for such business logic in other parts of their organization. This is a valuable step, and comes from an objective review of a new software project design with the developer, in the middle ground between business logic/requirements and raw code technology.
Don't let the 90's Dilbertification of modern business process deter you from having meetings. Meetings, done properly and with explicit policy on how to conduct them and why, are very effective.
It seems to me that the posters problem at this stage, is simply because they didn't have a meeting to review the design and overall gameplan for implementing the customers requirements, before they got started
Sure but its friggin stupid, you think you can fire a ball at high speed ? BULLSHIT, in a word, you every try to fire a paintball at > 500 fps ? 70 % of the time it just disentegrates in the barrel.
... I got in more trouble on the field doing that, than I did for over-taco'ing ...
... or hell, yeah ... even just a few cheap Tippmans could work, i'll bet.
Umm... re-read that, dude. I didn't mention speed, anywhere, in reference to control.
I could dial the cyber9k waaay down and it would 'softly' curve the ball
i'll be the military could use electro-pneumatics and range-finding, if they had to
In my opinion, this points to a decided lack of a proper design phase in you development process.
Does the client really not know enough about the design of what you are building for them, that they have made such an 'obvious' mis-comparison with the other project?
Design is more than just 'its going to work this way', its also 'its going to work this way, because'
bitchslap: "pfft. you clearly know -nothing- about paintball guns."
...
a good paintball gun will let you dial in whatever you want, and get the ball there. put an army-style range-finder on an electropneumatic, fill its hopper/feeder full of gummy-PIC's, fill the tank, charge the battery, calibrate, and you've got fieldable ball-placement in whatever nook and cranny you engender to explore
*sigh* i loved my cyber 9000, the few times it worked. i'm sure those guys have moved on to far better stuff...
One thing that you have to take into consideration is that Sharp probably doesn't expect to sell a whole lot of these things ... its fair to say that their treatment of the Zaurus product line (I have an SL-5500, love it to death...) is pretty much an afterthought, for the consumer market.
...
... I've been with PalmOS since day one, but this year I abandoned it completely and moved exclusively to Linux for my pocket computing needs ... and let me just say that it is tres-exciting, ssh'ing over WLAN to the bulge in my pocket where I've got bittorrent's sitting alive for the local 2600 meeting, ooh yeah ...
Instead, you'll see these things being used a lot by sytems integrators for business/commerce systems, and that explains the average higher cost for the Zaurus PDA's over other, equivalently featured products from competitors.
That said, the Zaurus is a whole lotta computer for what you pay and pretty much smokes the competition when it comes to programmability. When was the last time you spent a few hours tweaking the PalmOS kernel to exact every last bit of performance out of it? Well, that happens all the time in Zaurus land, and there are a really amazing wide range of options for this PDA, when it comes to distro's
Look for OpenEmbedded-based distro's in the future lineup of linux-based PDA's. It really is smooth and sexy
How about a story about the video projector I built out of a Reflecta 35mm slide projector and a Sega GameGear in the early '90
Actually yeah, I would be quite interested in hearing about that, since I am of the ilk that whatever physical endeavours a man chooses to waste his time on, its still a lot more interesting than hearing someone shit all over someone else, just because "it doesn't excite them"...
So tell me how you made a video projector. If its cheap, I might yet still learn something from you, even though you aren't being 'innovative'.
ummm ... its since been pointed out to me that my bookmark for "The Camera Van" has been borked/hijacked by a spycam outfit ... the site I was referring to is this one...
Half analogue, half digital? He's just scanning a large negative, hardly earth shattering.
...
What is with this freaking diminutive attitude? Is your life so shallow and meaningless that you can't see any beauty in the effort it took to set this up, from a geek angle?
Honestly, this is one hell of a cool project. So its not portable, so what? Its still some interesting science, well applied, to a real-life situation with good result.
The neg size is quite puny really. At Antwerpen Photograpic Museum I saw a camera which was HUGE - as tall as me. Took something like 4 foot negative plates.
Yeah, well while you're all "cool" and "elite" and everything for having visited Antwerp, on the web I saw this... and since it could drive to Antwerp and take a picture of your so-called 'cool place', it shits all over your 4 foot negative plates
Really. What a negative person you are.