I think you can pick up most of that knowledge from c. For that matter, c may become the new bar for practical low level knowledge.
As to embedded stuff, I imagine compilers are going to continue to get better and better at taking what the programmer wants to do and turning it into it's most efficient form. Languages will keep getting higher and higher level, and toolkits will continue to abstract more away from the user. We're already at a point where in many languages, all you need to know about a datatype is whether it's a number or a string. The tools figure out the best way to store and manipulate the underlying data.
We'll always need people who can explain whats happening down to where transistors are firing, but most programming jobs of the future are going to building on existing components using toolsets that hide most of the actual gory complexity. I think we're already at a point where you can be a good programmer without any knowledge below say, the java runtime environment. In other words, I'd put low level knowledge as a nice to have vice essential knowledge every programmer needs.
"I don't use wifi at home, it would probably suck for X forwarding, and certainly wouldn't be ideal for an isolated machine used for banking..." - why, exactly?
Someone turned on the microwave.. whelp, all those X apps are now hung. As a principle I think using wifi for anything that doesn't move is silly (hence why I don't use it at home, where all my machines are in fixed locations).
i guess you need gpio for banking errands
Did you even read the second line in my post. Using it to drive 2 displays and as a banking machine isn't all I plan on doing with the things, those were just two good uses I could do right away.
Decision logic:
RaspPi: GPIO and can probably run OpenDDS (or some form of DDS, RTi recently published an article about getting their solution to work) MK808B: Could probably be made to run DDS, no GPIO Arduino: GPIO, no way it's running DDS
The combination of GPIO and enough processing power to run complex software (like.. DDS) is what got me excited about the RaspPi when it was first announced. The fact that I've also used the RaspPi to solve some other problems in the interim for which the MK808B may have worked is irrelevant.
Lack of ethernet port would also stand out for those 3 use cases. I don't use wifi at home, it would probably suck for X forwarding, and certainly wouldn't be ideal for an isolated machine used for banking...
That aside, those are just my 3 immediate uses for it. I haven't had time to get any of my planned projects off the ground yet (my specific interest is GPIO + opendds (or some other dds-esq message/data middleware))...
Nothing wrong with people using other products that better suit ones needs, the hate part comes from people measuring the pi against alternatives that are either more expensive (at that scale, $10 is huge), doesn't do the same thing (no video output, runs android, etc..), or impossible to get hold of.
The stated goal early on was to be an ultra-cheap computer for students to mess around with, not to be a low cost SBC for production use. That said, it does make an awesome nerd toy, and probably will find real use in production in cases where random failures can be tolerated (driving the display monitors that seem to be all the rage everywhere seems a really good example).
People thought it would never get it off the ground. Then people thought it would never ship. Then that it would be plagued by problems and die. Then that it would never hold interest long enough to get to the point where you could get one without waiting 6 months.
There are still lots of haters, talking about how there are better “alternatives” out there (alternatives usually being 3 or 4 times the cost, impossible to get, or apples to oranges).
That said, I can order a perfectly functional unit, for the promised price, and have it here (in Canada) in about 4 days. I’ve got 5 of them now. I’d call that a huge success.
You brought something awesome into the world, and I thank you:)
That's pretty much the workflow I've seen most of my career. The big failing is when two people are working on large feature branches in the same area, but that can be mitigated by good project management (having two people working on different major changes in the same area is usually a terrible idea imo).
It's always usually possible to do a custom integration build for really big stuff (trunk + your branch(es)) and run the full test suite.
Oh I totally get you on clearcase. It's one of those tools that people often succeed not because of, but inspite of.
As to the origional argument, as someone said below, it comes down to scale and what's best for the specific project. Most of my career has been spent on large projects with many developers and in some cases multiple integration trunks, so I'm kinda skewed to the mindset that committing to trunk == ready and tested by developer. Everyone committing partially complete and untested work to trunk would be a complete mess.
That said I try to maintain the pragmatic view that if something is working and causing no problems, it's probably not wrong, regardless of what best practices and conventions say. If what you are doing is working at whatever scale you operate at, and you don't believe branches would enable you to work better in your workflow, then it's the right choice!
I don't know if that's really good advice anymore.
I mean if it's an interest, sure. Personally I love that stuff.. but unless you plan on doing low level coding for a career, modern programming is so abstract from machine language that knowing what's going on down there is in most cases interesting trivia at best.
Estimation is a dark art, and most people suck at it.
My best approach has always been to break a problem down into chunks, then break those chunks into smaller chunks, until I'm left with something granular enough to actually base an estimate on.
I'd expand on this by adding that not only is estimation an important skill, but self management is equally important. Is that chunk you thought would take a week now in it's third week? How is that going to affect the schedule (hint: I'll just do the next chunk faster is not a good path to go down..)? Recognizing how you are performing and identifying when you are about to blow the schedule while it can still be mitigated vice being just as surprised as your boss when it's way to late is a really good thing.
I'm all for CI (hudson/jenkins being my prefered tool of choice), but no feature branches? Lunacy!
I strongly believe integration has to be balanced. Sometimes people have to be able to run on their own for a bit then merge their work back in. Every commit going straight into trunk and expected to work is going to add lots of overhead and kill momentum.
That book is great and has aged really damn well. I still dig out my second edition copy from time to time. The "gory details" section is great when you are trying to figure out some obscure incantation that some sadistic bastard left as a present for you in a legacy script.
I'd still recommend reading that book cover to cover to anyone that wants to learn perl. You won't be a guru, but you'll have a pretty solid foundation.
Books can provide a nice "all inclusive" feeling for a broad topic, or even a specific one. There are lots of great online resources, but most are limited in scope, and learning that way can have a piecemeal feeling to it. Sometimes it's nice to have a topic covered from a starting point to an ending point by the same author(s) and in a consistent style.
Good example would be "Programming Perl". Sure, you can learn perl in pieces from the gazillion online resources (perlmonks is awesome), but if you read the book cover to cover, you get a kind of well thought out guided path through the language. Personally I've still got my (second edition) copy and occasionally dig it out... it's aged well and makes a great resource.
I'll admit I haven't read a book on anything computing related in a while, but I fear that's more because I haven't really learned anything thoroughly in a while, which kinda scares me...
I don't actually have a problem with advertising in general.. it just seems to really suck. Only time I ever really click on an ad is when the ad is so out there that I just have to know what they are selling (which I know is a tactic, but when they get me with it I figure they've earned my eyes for a minute or two).
As someone who is currently obsessed with a certain recently popular show, I totally agree on the fan fiction point. There's a huge pile of crap, but some of the stuff being produced by fans is mindblowingly good, with writing and editing on-par with professionally produced mid tier books.
Personally I love that technology is lowering the barrier to entry for this stuff. It's really happening with books, as self publishing is becoming a viable option. Music is pretty close, with ardour and lmms and cheap hardware, todays bedroom budget studios are pretty damn impressive, and lots of indy distribution sites. Video is still a ways off, but we are at a point now where people are producing entertaining content and making a little money off it.
I actually tried, but I can't think of any site revamp in the history of site revamps that I liked.
As someone above said, there seems to be this movement where UI (or in newspeak, "UX") experts are brought in with their doctrine of "right" and "wrong" interface design practices, and their egos which prevent them from re-evaluating their decisions when the entire user community tells them consistently and loudly that they don't like it.
When it's all over, a user either likes something or they don't. There will be an initial resistance to change, but once that's past if they are still complaining, regardless of whatever design laws you can use to justify your decision, it was wrong.
Not all posts advocating FOSS as the solution to all of lifes problems in the face of pragmatism are trolls. Some people legitimately have this mindset. I recognized the nick from an earlier discussion, otherwise I would have assumed troll (there's probably some meaning that can be taken from that).
That's a silly answer for most non-technical users.
Ignoring the extra hassle of hosting, an open source project can head in a direction you don't like just as easily, and unless you are prepared to fork the product (which a non-technical user probably can't) or just let it stagnate in a soup of unpatched exploits, you are just as helpless.
The epub thing is frustrating because other than that, I love mine as well.
It's the right size, weight, the touch screen is nice and responsive, it's got physical buttons for turning the page, and I love the lack of gimmicks (or at least that they are well hidden).
I've been hoping they'd put out an update to make the parser a bit less fragile, but I think at this point it's a lost cause.
I have a Sony PTS as well, and have indeed had bad luck with epub.
The core problem is there is no tolerance for error. One out of place tag or invalid character and it just explodes. This usually isn't a big deal for professionally made ebooks, but a lot of not-so professionally made ebooks have minor mistakes in the markup, and while web browsers have been dealing with these gracefully for years, the Sony ereader seems to just throw it's hands in the air and give up.
I too tried converting to PDF as a way around this, but was disappointed with that as well. Now I just convert to plain text for sources I know to be problematic.
Obviously Sony can't be entirely blamed here, it's being fed garbage data.. but a _little_ tolerance would be nice.
Where I get hung up, is that from the external perspective it makes perfect sense.
I put this in a comment above, but I'll paraphrase:
If we do this while I'm still alive, I'm now looking at another copy of myself that goes off and does it's own thing. I get that from an outside observer you've now got two entities running off the same "software" so to speak, starting with the same initial (copied) state and operating independently from there.
I can believe I'm just a product of billions of yes/no decisions, but I'm still here at this computer. If someone makes an exact copy, then I'm here looking at that copy (and presumably, that copy is over there looking back at me). I know this sounds like stoner speak, but it's the "I" and "me" part of that which I can't quite wrap my head around.
To use my lame software analogy, I guess I kinda see the brain as the software, and my conciousness, the "me" part of that, as an instance.
Someone above made a really interesting statement that maybe we are constantly cycling. I have all the memories and the "state" so to speak, but maybe "I've" only actually been alive as a conciousness for a day, or maybe just a few seconds.. who knows.
Lucky for me I have a coping mechanism. My brain throws an exception, I go "well that's just messed up", and go about my day.. and I plan to stay clear of any transport technology which revolves around killing me one place and "recreating" me another place;p
As I said, I get that you would have two (or more) new independent copies of yourself operating independently.
Lets do it while you are still alive, you are now looking at a copy of yourself that goes off and does its own thing as you said. What is that "you" part.
Slashdot Mirror
I think you can pick up most of that knowledge from c. For that matter, c may become the new bar for practical low level knowledge.
As to embedded stuff, I imagine compilers are going to continue to get better and better at taking what the programmer wants to do and turning it into it's most efficient form. Languages will keep getting higher and higher level, and toolkits will continue to abstract more away from the user. We're already at a point where in many languages, all you need to know about a datatype is whether it's a number or a string. The tools figure out the best way to store and manipulate the underlying data.
We'll always need people who can explain whats happening down to where transistors are firing, but most programming jobs of the future are going to building on existing components using toolsets that hide most of the actual gory complexity. I think we're already at a point where you can be a good programmer without any knowledge below say, the java runtime environment. In other words, I'd put low level knowledge as a nice to have vice essential knowledge every programmer needs.
"I don't use wifi at home, it would probably suck for X forwarding, and certainly wouldn't be ideal for an isolated machine used for banking..." - why, exactly?
Someone turned on the microwave.. whelp, all those X apps are now hung. As a principle I think using wifi for anything that doesn't move is silly (hence why I don't use it at home, where all my machines are in fixed locations).
i guess you need gpio for banking errands
Did you even read the second line in my post. Using it to drive 2 displays and as a banking machine isn't all I plan on doing with the things, those were just two good uses I could do right away.
Decision logic:
RaspPi: GPIO and can probably run OpenDDS (or some form of DDS, RTi recently published an article about getting their solution to work)
MK808B: Could probably be made to run DDS, no GPIO
Arduino: GPIO, no way it's running DDS
The combination of GPIO and enough processing power to run complex software (like.. DDS) is what got me excited about the RaspPi when it was first announced. The fact that I've also used the RaspPi to solve some other problems in the interim for which the MK808B may have worked is irrelevant.
Lack of ethernet port would also stand out for those 3 use cases. I don't use wifi at home, it would probably suck for X forwarding, and certainly wouldn't be ideal for an isolated machine used for banking...
That aside, those are just my 3 immediate uses for it. I haven't had time to get any of my planned projects off the ground yet (my specific interest is GPIO + opendds (or some other dds-esq message/data middleware))...
I've got 2 of them driving displays. Basically just running X with appropriate xauthority setup and synergy.
One of them I'm using as an isolated computer to do all my banking/financial stuff on. This replaces a an old P2 box I was using for this purpose.
Another I'm just messing around with (playing with the GPIO pins mostly).
And I've still got one still in the box.
That list of differences wasn't specifically against the mentioned alternative.
I haven't specifically looked into the MK808B, but just based on a quick image search, the lack of GPIO pins stands out.
Nothing wrong with people using other products that better suit ones needs, the hate part comes from people measuring the pi against alternatives that are either more expensive (at that scale, $10 is huge), doesn't do the same thing (no video output, runs android, etc..), or impossible to get hold of.
I think that was kinda the intent though.
The stated goal early on was to be an ultra-cheap computer for students to mess around with, not to be a low cost SBC for production use. That said, it does make an awesome nerd toy, and probably will find real use in production in cases where random failures can be tolerated (driving the display monitors that seem to be all the rage everywhere seems a really good example).
People thought it would never get it off the ground. Then people thought it would never ship. Then that it would be plagued by problems and die. Then that it would never hold interest long enough to get to the point where you could get one without waiting 6 months.
There are still lots of haters, talking about how there are better “alternatives” out there (alternatives usually being 3 or 4 times the cost, impossible to get, or apples to oranges).
That said, I can order a perfectly functional unit, for the promised price, and have it here (in Canada) in about 4 days. I’ve got 5 of them now. I’d call that a huge success.
You brought something awesome into the world, and I thank you :)
That's pretty much the workflow I've seen most of my career. The big failing is when two people are working on large feature branches in the same area, but that can be mitigated by good project management (having two people working on different major changes in the same area is usually a terrible idea imo).
It's always usually possible to do a custom integration build for really big stuff (trunk + your branch(es)) and run the full test suite.
Oh I totally get you on clearcase. It's one of those tools that people often succeed not because of, but inspite of.
As to the origional argument, as someone said below, it comes down to scale and what's best for the specific project. Most of my career has been spent on large projects with many developers and in some cases multiple integration trunks, so I'm kinda skewed to the mindset that committing to trunk == ready and tested by developer. Everyone committing partially complete and untested work to trunk would be a complete mess.
That said I try to maintain the pragmatic view that if something is working and causing no problems, it's probably not wrong, regardless of what best practices and conventions say. If what you are doing is working at whatever scale you operate at, and you don't believe branches would enable you to work better in your workflow, then it's the right choice!
I don't know if that's really good advice anymore.
I mean if it's an interest, sure. Personally I love that stuff.. but unless you plan on doing low level coding for a career, modern programming is so abstract from machine language that knowing what's going on down there is in most cases interesting trivia at best.
But never make the prototype too good.
"You need 12 weeks to turn it into actual software? this works fine!"
Yup!
Estimation is a dark art, and most people suck at it.
My best approach has always been to break a problem down into chunks, then break those chunks into smaller chunks, until I'm left with something granular enough to actually base an estimate on.
I'd expand on this by adding that not only is estimation an important skill, but self management is equally important. Is that chunk you thought would take a week now in it's third week? How is that going to affect the schedule (hint: I'll just do the next chunk faster is not a good path to go down..)? Recognizing how you are performing and identifying when you are about to blow the schedule while it can still be mitigated vice being just as surprised as your boss when it's way to late is a really good thing.
I'm all for CI (hudson/jenkins being my prefered tool of choice), but no feature branches? Lunacy!
I strongly believe integration has to be balanced. Sometimes people have to be able to run on their own for a bit then merge their work back in. Every commit going straight into trunk and expected to work is going to add lots of overhead and kill momentum.
That book is great and has aged really damn well. I still dig out my second edition copy from time to time. The "gory details" section is great when you are trying to figure out some obscure incantation that some sadistic bastard left as a present for you in a legacy script.
I'd still recommend reading that book cover to cover to anyone that wants to learn perl. You won't be a guru, but you'll have a pretty solid foundation.
Books can provide a nice "all inclusive" feeling for a broad topic, or even a specific one. There are lots of great online resources, but most are limited in scope, and learning that way can have a piecemeal feeling to it. Sometimes it's nice to have a topic covered from a starting point to an ending point by the same author(s) and in a consistent style.
Good example would be "Programming Perl". Sure, you can learn perl in pieces from the gazillion online resources (perlmonks is awesome), but if you read the book cover to cover, you get a kind of well thought out guided path through the language. Personally I've still got my (second edition) copy and occasionally dig it out... it's aged well and makes a great resource.
I'll admit I haven't read a book on anything computing related in a while, but I fear that's more because I haven't really learned anything thoroughly in a while, which kinda scares me...
Pretty much this.
I don't actually have a problem with advertising in general.. it just seems to really suck. Only time I ever really click on an ad is when the ad is so out there that I just have to know what they are selling (which I know is a tactic, but when they get me with it I figure they've earned my eyes for a minute or two).
As someone who is currently obsessed with a certain recently popular show, I totally agree on the fan fiction point. There's a huge pile of crap, but some of the stuff being produced by fans is mindblowingly good, with writing and editing on-par with professionally produced mid tier books.
Personally I love that technology is lowering the barrier to entry for this stuff. It's really happening with books, as self publishing is becoming a viable option. Music is pretty close, with ardour and lmms and cheap hardware, todays bedroom budget studios are pretty damn impressive, and lots of indy distribution sites. Video is still a ways off, but we are at a point now where people are producing entertaining content and making a little money off it.
Totally with you.
I actually tried, but I can't think of any site revamp in the history of site revamps that I liked.
As someone above said, there seems to be this movement where UI (or in newspeak, "UX") experts are brought in with their doctrine of "right" and "wrong" interface design practices, and their egos which prevent them from re-evaluating their decisions when the entire user community tells them consistently and loudly that they don't like it.
When it's all over, a user either likes something or they don't. There will be an initial resistance to change, but once that's past if they are still complaining, regardless of whatever design laws you can use to justify your decision, it was wrong.
Not all posts advocating FOSS as the solution to all of lifes problems in the face of pragmatism are trolls. Some people legitimately have this mindset. I recognized the nick from an earlier discussion, otherwise I would have assumed troll (there's probably some meaning that can be taken from that).
That's a silly answer for most non-technical users.
Ignoring the extra hassle of hosting, an open source project can head in a direction you don't like just as easily, and unless you are prepared to fork the product (which a non-technical user probably can't) or just let it stagnate in a soup of unpatched exploits, you are just as helpless.
The epub thing is frustrating because other than that, I love mine as well.
It's the right size, weight, the touch screen is nice and responsive, it's got physical buttons for turning the page, and I love the lack of gimmicks (or at least that they are well hidden).
I've been hoping they'd put out an update to make the parser a bit less fragile, but I think at this point it's a lost cause.
I have a Sony PTS as well, and have indeed had bad luck with epub.
The core problem is there is no tolerance for error. One out of place tag or invalid character and it just explodes. This usually isn't a big deal for professionally made ebooks, but a lot of not-so professionally made ebooks have minor mistakes in the markup, and while web browsers have been dealing with these gracefully for years, the Sony ereader seems to just throw it's hands in the air and give up.
I too tried converting to PDF as a way around this, but was disappointed with that as well. Now I just convert to plain text for sources I know to be problematic.
Obviously Sony can't be entirely blamed here, it's being fed garbage data.. but a _little_ tolerance would be nice.
Where I get hung up, is that from the external perspective it makes perfect sense.
I put this in a comment above, but I'll paraphrase:
If we do this while I'm still alive, I'm now looking at another copy of myself that goes off and does it's own thing. I get that from an outside observer you've now got two entities running off the same "software" so to speak, starting with the same initial (copied) state and operating independently from there.
I can believe I'm just a product of billions of yes/no decisions, but I'm still here at this computer. If someone makes an exact copy, then I'm here looking at that copy (and presumably, that copy is over there looking back at me). I know this sounds like stoner speak, but it's the "I" and "me" part of that which I can't quite wrap my head around.
To use my lame software analogy, I guess I kinda see the brain as the software, and my conciousness, the "me" part of that, as an instance.
Someone above made a really interesting statement that maybe we are constantly cycling. I have all the memories and the "state" so to speak, but maybe "I've" only actually been alive as a conciousness for a day, or maybe just a few seconds.. who knows.
Lucky for me I have a coping mechanism. My brain throws an exception, I go "well that's just messed up", and go about my day.. and I plan to stay clear of any transport technology which revolves around killing me one place and "recreating" me another place ;p
As I said, I get that you would have two (or more) new independent copies of yourself operating independently.
Lets do it while you are still alive, you are now looking at a copy of yourself that goes off and does its own thing as you said. What is that "you" part.