For those unaware, an assault rifle is a firearm capable of firing in a fully automatic mode, as opposed to semi-automatic or single-action. Furthermore, the most common round used in assault rifles is a pittance, it is a.22 caliber bullet (granted with a lot more power and better aerodynamics than the.22 LR you shoot in Boy Scouts). But even with all that it is considered pitiful, not much more than a varmint round.
Here in Pennsylvania it is illegal to hunt dear with a.223 caliber because it is not considered powerful enough to ensure a clean kill. In fact, those evil high caliber rounds are often half the size of a hunting cartridge.
So where does the term "high power" stem from? Not the cartridge itself. But the capacity of the firearm. Essentially, you had a 45 caliber semi-automatic designed by the Revered John Moses Browning. This held about 8 rounds. They're big short fat stubby rounds. 8 rounds of firepower was two more than the average revolver. The Revered than creating the Browning Hi-Power using a much smaller 9mm round. The result was a capacity of 15-19 rounds. Hence hi-power simply mean greater capacity, often related to small, weaker, less powerful bullets.
In fact, the current.223 round used in M16/M4/AR15 (semi-automatic version) is essentially considered the smallest, weakest, bare minimum rifle round that can ensure a reasonable expectation of success. Compared to what gramps used in WWII or worse, WWI, it's laughable - unless you're shot by one of course.
It all started when you morons cheered for "No Flash"...did you really !@#$% think it would stop there?
Ya, I'm laughing, cause you guys merely proved to me that I was right, and Slashdot was mostly morons. Yes, I'm trolling....and I've caught some big ones. But seriously, are you guys blind?
OOP becomes "Lasagna Code", as least procedural code allows you to follow the spaghettic noodle of code logic. OOP lasagna code essentially leaves you wondering what piece of cheese is triggering your sausage.
Granted, you get to easily determine if you're dealing with sausage, sauce, cheese or even a extended sub class of Rigotta cheese. But unmapped OOP I fear will be far worse than the spaghetti code of yesteryear.
1. Assess the present stability of code? Is it for the most part functioning? If there are a handful of critical errors. Address those, but do not get bogged down.
2. Assess the core requirements. When I worked on a medical practice management application we had tons of requirements. Many of which we were told were ABSOLUTELY CRITICAL to the practice. A year later we'd find out said feature had not even been used once.
Determine what features/actions are core....re-write these in new code with a critical eye to performance and stability.
3. Run concurrent systems, transition 90% of core tasks to the new re-written, more extendable and adaptable code. Realize there will be some compromise on perfection in order to inter-operate.
Leave uncommon tasks to the old antiquated system. Sure it sucks for a user to have to log into the old system 3-4 times a year to run some quarterly task or procedure. But it's something most users can deal with, and will do so with only minimal griping. Especially if the core tasks are now functioning at an improved level.
4. Road map features and slowly add new feature requests or migrate old features to the new app as is required by user need. Why map an old feature that's used 1-2 times a year if a new feature is needed everyday. Why add a new featured used 1-2 a year if an old one that is used weekly can be migrated instead.
5. Enjoy the fact that you're not unemployed and homeless. Yes, the guy who posted up above exclaimed he'd rather be homeless. But I wager most people are smart enough to know that undesired homelessness without a support system sucks. And would prefer NOT to be there.
Really, having to write 4 templates, and modify 1/2 a dozen others, in order to output a simply query/list is good code?
Yes, that's pretty common in most of today's OOP/MVC/decoupled architecture frameworks of today. At least procedural code can be followed by it's procedural nature. Come into a framework without a roadmap. And you often are doing immense legwork to find where something is triggered from or what something is responding too.
I wager in 20-30 years, this will be called "lasagna code" because you won't even be able to follow a single thread of spaghetti anywhere.
I am sure that when developers look at our code in 20 years from now. They will refer to it as Spaghetti code. Especially when they work with a lot of the convoluted implementations of MVC inspired frameworks. They'll wonder what the !@#$% were we thinking?
They'll wonder why for a simple query they have to create four new templates and modify a 1/2 dozen more. They're wonder why there is no reference guide to link to these. And how they're stuck following a trail of breadcrumbs. They'll be flabbergasted to think that we thought we were somehow decoupling things when in fact we greatly increased the interdependence of files.
Yes, in 20-30 years, our great decoupled object-oriented programming will likely be the spaghetti code of it's day and be viewed as archaic as the use of GoTo logic.
***
And unlike procedural spaghetti code in which one could often follow the logic procedurally. OOP spaghettic code often is so decoupled that it is extremely hard to follow or discover what and where something may be called from if you do not have some sort of road map.
And let's be honest, do you really think our usually poorly documented roadmaps for our OOP apps will be existent for the developers in 20+ years?
Do you really think there was no documentation whatsoever for all these applications written in COBOl six decades ago? Back when it was almost standard to first write a PSEUDO code version of an app.
No, we just tend to be more arrogant because we're "uptime"...
Because form follows function, and because most designs have existed in concept well before.
Seriously, in a few years Apple will come out with a transparent phone. And sue everyone else who does. Regardless of how many examples of that exact same design have been mocked up as fake rumor gags.
Oh, and there was not really much evolution of design other than to reduce the buttons. This was in fact evolutionary as price of screens were dropping and one could afford to place a larger screen with enough real estate to move more of the buttons into virtual buttons.
But virtual buttons already exist in a zillion applications.
So this really boils down to, is one button a patentable offense?
Guilt has already been set. This was basically an order to protect the rapists reputation and prevent her from being able to talk about WHO raped her post conviction and sentence.
Makes no sense to introduce an exhibit of caveman painting on caves. But when you have a similar looking phone design that is very much related to the case at hand. It should be admissable.
If a man has 6 prior charges of rape, even if no juries could conclude there was enough evidence to convict. THAT should be admissable evidence.
A pretty crude fully automatic grease gun is probably manufacturable today with technology available. No, it wouldn't be great or super reliable. Just print off a few extra copies.
Yes, but form follows function as technology allows.
Most devices were big, clunky, etc. Because parts were bigger, clunky, etc. The truth is, we'd have probably seen an iPhone in 1-2 years regardless of Apple.
Also, this is nearly akin to saying you can't have a mouse, because Apple has a one button mouse. But no mouses are allowed by anyone but Apple.
Yes, but you have to consider was that 2005 prototype in Samsung's hands? If not, you have independent designs.
Also realize, that almost ALL these designs are evolutionary. We're essentially talking about the reduction of buttons down to one visible button on the front. Is that patent worthy?
So a new rental car I drove took all the buttons and used a LCD screen menu, and a single knob to scroll through and select. Should no other car be able to use such a system.
Oh, the same menu selection system is also on my Canon 40D. Hmm...
Seriously, we're talking about one button vs a small collection of buttons. That's really the sole difference.
I mean, my HTC 6700 was essentially the same form factor as an iPhone. Granted thicker cause it's older, and it had an antenna nub. But the main difference is there was a small conglomeration of like 5 buttons vs the one button.
And that is the difference...sorry, that is NOT !@#$% invention. This case should be dismissed with extreme prejudice and Apple should be fined $1 billion for filing the case.
Who gives a darn about legality, it's about morality.
Oh, and her name is out...the victim should never suffer worse judments than the criminal. That is injustice. And legal be damned, legal is evil. Legal is what allowed slavery, legal is what allowed abuse of immigrants, morality is what counts.
None of this is invention...this is all about style. And style should NOT be patentable. Especially when it is evolutionary and tied to use design. By which I mean the use of a tool determines it's design.
A shovel, regardless of design will likely have a handle, and a broad flat shape attached to the end. Whether it is slightly tapered to a spade, extra wide for snow, or narrow and elongated for trench digging are merely evolutions of an inherent use design.
It is only a matter of time before someone offers a printable design which requires nothing more than a pre-fab pipe and a few springs from Home Depot...and everything else is printed.
In fact, a fully automatic firearm is easier to manufacture than a semi-automatic, ironically.
Slashdot Mirror
You must be a liberal....they always seem so violent for some reason?
For those unaware, an assault rifle is a firearm capable of firing in a fully automatic mode, as opposed to semi-automatic or single-action. Furthermore, the most common round used in assault rifles is a pittance, it is a .22 caliber bullet (granted with a lot more power and better aerodynamics than the .22 LR you shoot in Boy Scouts). But even with all that it is considered pitiful, not much more than a varmint round.
Here in Pennsylvania it is illegal to hunt dear with a .223 caliber because it is not considered powerful enough to ensure a clean kill. In fact, those evil high caliber rounds are often half the size of a hunting cartridge.
So where does the term "high power" stem from? Not the cartridge itself. But the capacity of the firearm. Essentially, you had a 45 caliber semi-automatic designed by the Revered John Moses Browning. This held about 8 rounds. They're big short fat stubby rounds. 8 rounds of firepower was two more than the average revolver. The Revered than creating the Browning Hi-Power using a much smaller 9mm round. The result was a capacity of 15-19 rounds. Hence hi-power simply mean greater capacity, often related to small, weaker, less powerful bullets.
In fact, the current .223 round used in M16/M4/AR15 (semi-automatic version) is essentially considered the smallest, weakest, bare minimum rifle round that can ensure a reasonable expectation of success. Compared to what gramps used in WWII or worse, WWI, it's laughable - unless you're shot by one of course.
I would, I mean seriously...fair chance the rifle was worth more...and in DC wow....
Yes, you are quite right. I apologize to my Italian heritage for my typo.
And that's Mr. Fucktard to you!
(by the way, what stupid 'tards decided that languages like French and Italian would write letters that they would never pronounce?)
It all started when you morons cheered for "No Flash"...did you really !@#$% think it would stop there?
Ya, I'm laughing, cause you guys merely proved to me that I was right, and Slashdot was mostly morons. Yes, I'm trolling....and I've caught some big ones. But seriously, are you guys blind?
Did you NOT expect this?
Yes it does....
OOP becomes "Lasagna Code", as least procedural code allows you to follow the spaghettic noodle of code logic. OOP lasagna code essentially leaves you wondering what piece of cheese is triggering your sausage.
Granted, you get to easily determine if you're dealing with sausage, sauce, cheese or even a extended sub class of Rigotta cheese. But unmapped OOP I fear will be far worse than the spaghetti code of yesteryear.
Be afraid, "lasagna code" cometh...
The first things to do are the following:
1. Assess the present stability of code? Is it for the most part functioning? If there are a handful of critical errors. Address those, but do not get bogged down.
2. Assess the core requirements. When I worked on a medical practice management application we had tons of requirements. Many of which we were told were ABSOLUTELY CRITICAL to the practice. A year later we'd find out said feature had not even been used once.
Determine what features/actions are core....re-write these in new code with a critical eye to performance and stability.
3. Run concurrent systems, transition 90% of core tasks to the new re-written, more extendable and adaptable code. Realize there will be some compromise on perfection in order to inter-operate.
Leave uncommon tasks to the old antiquated system. Sure it sucks for a user to have to log into the old system 3-4 times a year to run some quarterly task or procedure. But it's something most users can deal with, and will do so with only minimal griping. Especially if the core tasks are now functioning at an improved level.
4. Road map features and slowly add new feature requests or migrate old features to the new app as is required by user need. Why map an old feature that's used 1-2 times a year if a new feature is needed everyday. Why add a new featured used 1-2 a year if an old one that is used weekly can be migrated instead.
5. Enjoy the fact that you're not unemployed and homeless. Yes, the guy who posted up above exclaimed he'd rather be homeless. But I wager most people are smart enough to know that undesired homelessness without a support system sucks. And would prefer NOT to be there.
Really, having to write 4 templates, and modify 1/2 a dozen others, in order to output a simply query/list is good code?
Yes, that's pretty common in most of today's OOP/MVC/decoupled architecture frameworks of today. At least procedural code can be followed by it's procedural nature. Come into a framework without a roadmap. And you often are doing immense legwork to find where something is triggered from or what something is responding too.
I wager in 20-30 years, this will be called "lasagna code" because you won't even be able to follow a single thread of spaghetti anywhere.
I am sure that when developers look at our code in 20 years from now. They will refer to it as Spaghetti code. Especially when they work with a lot of the convoluted implementations of MVC inspired frameworks. They'll wonder what the !@#$% were we thinking?
They'll wonder why for a simple query they have to create four new templates and modify a 1/2 dozen more. They're wonder why there is no reference guide to link to these. And how they're stuck following a trail of breadcrumbs. They'll be flabbergasted to think that we thought we were somehow decoupling things when in fact we greatly increased the interdependence of files.
Yes, in 20-30 years, our great decoupled object-oriented programming will likely be the spaghetti code of it's day and be viewed as archaic as the use of GoTo logic.
***
And unlike procedural spaghetti code in which one could often follow the logic procedurally. OOP spaghettic code often is so decoupled that it is extremely hard to follow or discover what and where something may be called from if you do not have some sort of road map.
And let's be honest, do you really think our usually poorly documented roadmaps for our OOP apps will be existent for the developers in 20+ years?
Do you really think there was no documentation whatsoever for all these applications written in COBOl six decades ago? Back when it was almost standard to first write a PSEUDO code version of an app.
No, we just tend to be more arrogant because we're "uptime"...
1632
Oh, wait...so Apple is not listing a patent number eh?
Oh, wait...this design is so radical....
Round edges....wait, just like my HTC 6700 which looks fairly similar to the iPhone when you account that the iPhone was able to drop the atenna nub.
Because form follows function, and because most designs have existed in concept well before.
Seriously, in a few years Apple will come out with a transparent phone. And sue everyone else who does. Regardless of how many examples of that exact same design have been mocked up as fake rumor gags.
Oh, and there was not really much evolution of design other than to reduce the buttons. This was in fact evolutionary as price of screens were dropping and one could afford to place a larger screen with enough real estate to move more of the buttons into virtual buttons.
But virtual buttons already exist in a zillion applications.
So this really boils down to, is one button a patentable offense?
Guilt has already been set. This was basically an order to protect the rapists reputation and prevent her from being able to talk about WHO raped her post conviction and sentence.
Okay, let me clarify....ALL RELATED evidence.
Makes no sense to introduce an exhibit of caveman painting on caves. But when you have a similar looking phone design that is very much related to the case at hand. It should be admissable.
If a man has 6 prior charges of rape, even if no juries could conclude there was enough evidence to convict. THAT should be admissable evidence.
Yes it is...we need to argue against the broken patent law system at every opportunity and in every venue.
But the problem is, that we have evidence of digging.
Exhibit A: Childing digging in sandbox by hand.
Exhibit B: Digging being done with large flat rock.
Exhibit C: Shovel being used to dig...
Oh, but your shovel is stainless and doesn't rust. No one else can make a stainless steel shovel. (That is ESSENTIALLY, what Apple is arguing)
A pretty crude fully automatic grease gun is probably manufacturable today with technology available. No, it wouldn't be great or super reliable. Just print off a few extra copies.
The point is in 10 years it will be no challenge.
Thanks, I think you just confirmed for me Apple has no real case outside of a messed up judicial/legal system.
Yes, but form follows function as technology allows.
Most devices were big, clunky, etc. Because parts were bigger, clunky, etc. The truth is, we'd have probably seen an iPhone in 1-2 years regardless of Apple.
Also, this is nearly akin to saying you can't have a mouse, because Apple has a one button mouse. But no mouses are allowed by anyone but Apple.
Yes, a single button an invention does not make.
Flat, rounded corners, with display akin to Captain Jean-Luc Picard's datapad in the 80's Star Trek a patentable invention does not make.
Sorry...this case shouldn't have even gone to trial.
Yes, but you have to consider was that 2005 prototype in Samsung's hands? If not, you have independent designs.
Also realize, that almost ALL these designs are evolutionary. We're essentially talking about the reduction of buttons down to one visible button on the front. Is that patent worthy?
So a new rental car I drove took all the buttons and used a LCD screen menu, and a single knob to scroll through and select. Should no other car be able to use such a system.
Oh, the same menu selection system is also on my Canon 40D. Hmm...
This SHOULD NOT be patentable.
Seriously, we're talking about one button vs a small collection of buttons. That's really the sole difference.
I mean, my HTC 6700 was essentially the same form factor as an iPhone. Granted thicker cause it's older, and it had an antenna nub. But the main difference is there was a small conglomeration of like 5 buttons vs the one button.
And that is the difference...sorry, that is NOT !@#$% invention. This case should be dismissed with extreme prejudice and Apple should be fined $1 billion for filing the case.
Who gives a darn about legality, it's about morality.
Oh, and her name is out...the victim should never suffer worse judments than the criminal. That is injustice. And legal be damned, legal is evil. Legal is what allowed slavery, legal is what allowed abuse of immigrants, morality is what counts.
I am of the opinion ALL evidence should be submittable.
None of this is invention...this is all about style. And style should NOT be patentable. Especially when it is evolutionary and tied to use design. By which I mean the use of a tool determines it's design.
A shovel, regardless of design will likely have a handle, and a broad flat shape attached to the end. Whether it is slightly tapered to a spade, extra wide for snow, or narrow and elongated for trench digging are merely evolutions of an inherent use design.
It is only a matter of time before someone offers a printable design which requires nothing more than a pre-fab pipe and a few springs from Home Depot...and everything else is printed.
In fact, a fully automatic firearm is easier to manufacture than a semi-automatic, ironically.