There are at least two in Indianapolis - One on the west side of Meridian Street at Georgia and another on the east side of Meridian Street at Maryland.
Re:A Day in the Life of an ADHD suferer
on
Working with ADHD?
·
· Score: 2, Interesting
If this in not irrefutable proof that you should recieve karma for a post modded +1 Funny, I don't know what is. This post alone more than makes up for the plethera of bad puns, haiku, and MS-basing that passes for funny here on/.
The correct level of abstraction for a project is often hard to find, even for very experienced programmers. Sometimes you have to raise the level of abstraction of an overall system, or you will never get to the point where you can move forward on your piece of the process. Generally, I've found that the problems lie in the areas where the pieces don't quite fit together properly; namely where one person's code doesn't follow the contract a second person was expecting. A lot of the time, even for mid-size problems, it would be impossible for one developer (or a team) to have an end-to-end understanding of the problem space.
As far as I can tell, there is only one way to avoid the "black-box" problem, and that is to have one person code the whole thing, which is very likely infeasable. The further you get from "your" part of the system, the more abstract it is going to get. If your abstraction is faulty, there is going to be trouble, but I wouldn't say it was caused by treating the problem as a black box.
I assumed the reason they suspended the tourist program is to clear more cargo room, since it will be needed (for a while anyway) as the sole way to restock the space station.
But, you are right, if it was done for safety reasons, that is ridiculous. If they didn't realize the safety risk before last Saturday, what business did they (the tourist) have up there anyway?
Another good reference for this type of info is The Pragmatic Programmer. It lays out how to write flexible, dynamic, and adaptable code, as well avoiding traps that a lot of new programmers fall into. It takes the time to explain the "why's" behind a lot of the engineering approaches advanced programmers take. It is definitely aimed at "junior" programmers, though. Usually when we get someone just out of collage, I point them to this book.
This book is invaluable.
on
Effective Java
·
· Score: 5, Interesting
There are a lot of Java books out there, but this is one that will help an intermediate-to-advanced Java developer. The code examples in here are concise, clean, and hard-hitting. The layout of the book allows you to pick it up and learn something if you have 10 minutes or 2 hours.
When I was first learning Java, I often had that nagging feeling that I was making things harder on myself than need be. This book cleared up a lot of those feelings, and helped get me on the right track for some of the great tools hidden away in the Java API. The API documentation is great for showing you what members and functions are available to an engineer, but this book shows you how to use the API. The review cites the author's avocation of knowing the libraries, I would contend that this book would help you get the most out of those libraries, and increase your understanding of them.
This book has become a must-have around my office, and if you are looking to get over-the-hump and move from an intermediate to advanced java software engineer, pick up this book. It is dense with information, and will save you a ton of time and energy. What more could you ask for from a book?
And with that upgrade, you lose your "life-time" subscription, since it will be tied to your old box. Basically, the break-even point on the lifetime subscription versus the pay-as-you-go is about two years, if I remember correctly. I'm not sure that many people on this upgrade path will make the break-even point.
I think any more, you can measure a device's horsepower, all you have to do is ask yourself "Will it run MAME?" First it was PC/Mac/LINUX/BeOS, then it was Dreamcast/GBA/etc. Next came digital cameras, now cel phones. You can almost measure the advancement of a platform purely by when it will run MAME.
I hope IBM's intention is to keep Rational evolving UML/RUP and not to strip out Clear Case, Req Pro, and Rose. A lot of the time, this is what happens when a big company buys a company like that, and it would be a real shame if this happened to Rational. Personally, I think UML and RUP continue to gain mindshare when it comes to Software Engineering Methodology.
Grady Booch recently spoke at our company, and his enthusiasm was infectious! It is obvious that he and the other Rational Fellows have a pretty good vision of where UML and RUP should go, and it would be a real shame if that was lost.
The one bad thing that strikes me about this book is actually just a simple question: Why should I use it when most of this information is at my fingertips in an IDE?
I like having this sort of info in print, even though what you say is true, it is available from most IDEs. It is nice to be able to put a post-it note or write a reminder in some classes who's method signature are not too intuative.
Having been a java programmer for 3 or so years, I think Java 1.4 is a big step forward, and a lot of the newer packages are great additions (the logging package, for example). The flexability of that package alone makes Java a lot more robust and attractive.
Embedded developers can use thier own thread libraries. Multiprocessor systems are becomming more and more common. It seems that the most scalable implementation(NGPT) should be used in order to minimize future chages. It would seem that the published benchmarks used NGPT on a slower context-switchign kernel. The NPTL is proabably still faster for small numbers of threads, but I would guess that "big-iron" performance is better with NGPT. NGPT also is a more flexible implementation. A well-maintained and widely testd user-space threading library makes it easier to patch in customized intra-process thread schedulers with reasonable assurances of stability.
Slashdot Mirror
There are at least two in Indianapolis - One on the west side of Meridian Street at Georgia and another on the east side of Meridian Street at Maryland.
If this in not irrefutable proof that you should recieve karma for a post modded +1 Funny, I don't know what is. This post alone more than makes up for the plethera of bad puns, haiku, and MS-basing that passes for funny here on /.
Bravo!
The correct level of abstraction for a project is often hard to find, even for very experienced programmers. Sometimes you have to raise the level of abstraction of an overall system, or you will never get to the point where you can move forward on your piece of the process. Generally, I've found that the problems lie in the areas where the pieces don't quite fit together properly; namely where one person's code doesn't follow the contract a second person was expecting. A lot of the time, even for mid-size problems, it would be impossible for one developer (or a team) to have an end-to-end understanding of the problem space.
As far as I can tell, there is only one way to avoid the "black-box" problem, and that is to have one person code the whole thing, which is very likely infeasable. The further you get from "your" part of the system, the more abstract it is going to get. If your abstraction is faulty, there is going to be trouble, but I wouldn't say it was caused by treating the problem as a black box.
I assumed the reason they suspended the tourist program is to clear more cargo room, since it will be needed (for a while anyway) as the sole way to restock the space station.
But, you are right, if it was done for safety reasons, that is ridiculous. If they didn't realize the safety risk before last Saturday, what business did they (the tourist) have up there anyway?
Another good reference for this type of info is The Pragmatic Programmer. It lays out how to write flexible, dynamic, and adaptable code, as well avoiding traps that a lot of new programmers fall into. It takes the time to explain the "why's" behind a lot of the engineering approaches advanced programmers take. It is definitely aimed at "junior" programmers, though. Usually when we get someone just out of collage, I point them to this book.
There are a lot of Java books out there, but this is one that will help an intermediate-to-advanced Java developer. The code examples in here are concise, clean, and hard-hitting. The layout of the book allows you to pick it up and learn something if you have 10 minutes or 2 hours.
When I was first learning Java, I often had that nagging feeling that I was making things harder on myself than need be. This book cleared up a lot of those feelings, and helped get me on the right track for some of the great tools hidden away in the Java API. The API documentation is great for showing you what members and functions are available to an engineer, but this book shows you how to use the API. The review cites the author's avocation of knowing the libraries, I would contend that this book would help you get the most out of those libraries, and increase your understanding of them.
This book has become a must-have around my office, and if you are looking to get over-the-hump and move from an intermediate to advanced java software engineer, pick up this book. It is dense with information, and will save you a ton of time and energy. What more could you ask for from a book?
And with that upgrade, you lose your "life-time" subscription, since it will be tied to your old box. Basically, the break-even point on the lifetime subscription versus the pay-as-you-go is about two years, if I remember correctly. I'm not sure that many people on this upgrade path will make the break-even point.
I think any more, you can measure a device's horsepower, all you have to do is ask yourself "Will it run MAME?" First it was PC/Mac/LINUX/BeOS, then it was Dreamcast/GBA/etc. Next came digital cameras, now cel phones. You can almost measure the advancement of a platform purely by when it will run MAME.
I hope IBM's intention is to keep Rational evolving UML/RUP and not to strip out Clear Case, Req Pro, and Rose. A lot of the time, this is what happens when a big company buys a company like that, and it would be a real shame if this happened to Rational. Personally, I think UML and RUP continue to gain mindshare when it comes to Software Engineering Methodology.
Grady Booch recently spoke at our company, and his enthusiasm was infectious! It is obvious that he and the other Rational Fellows have a pretty good vision of where UML and RUP should go, and it would be a real shame if that was lost.
The one bad thing that strikes me about this book is actually just a simple question: Why should I use it when most of this information is at my fingertips in an IDE?
I like having this sort of info in print, even though what you say is true, it is available from most IDEs. It is nice to be able to put a post-it note or write a reminder in some classes who's method signature are not too intuative.
Having been a java programmer for 3 or so years, I think Java 1.4 is a big step forward, and a lot of the newer packages are great additions (the logging package, for example). The flexability of that package alone makes Java a lot more robust and attractive.I liked it better the first time I played it, when it was called "Simon".
Embedded developers can use thier own thread libraries. Multiprocessor systems are becomming more and more common. It seems that the most scalable implementation(NGPT) should be used in order to minimize future chages. It would seem that the published benchmarks used NGPT on a slower context-switchign kernel. The NPTL is proabably still faster for small numbers of threads, but I would guess that "big-iron" performance is better with NGPT. NGPT also is a more flexible implementation. A well-maintained and widely testd user-space threading library makes it easier to patch in customized intra-process thread schedulers with reasonable assurances of stability.