Unfortunately, this has absolutely no chance of success. Motions for Summary Judgment are generally denied unless the other side's argument is so flimsy that there is no shot at it succeeding at trial, and is wasting the court's time. However, since a judge can't just dismiss a civil action for being st00pid, s/he generally first tries to get the parties to settle, and then tries to encourage the plaintiff (or defendant) to punt, to save them the embarrassment of granting a MSJ. If they refuse, then this might succeed.
In a case like this, though, where the facts and evidence are sure to be the crux of matters, there is no way the judge will grant it, which is unfortunate.
When the new high-power sonar systems were being tested, they asked for SCUBA divers to participate. This was at a certain test location that is literally out in the middle of the ocean. It wasn't like they took you out there. You were either already there or you weren't. Among other things, the time that divers were in the water, and the exact spot were requested, along with personal experiences and observations of what the "wildlife" was doing. Since the location is a remote base, they were pretty confident that the reports were reasonable.
Howdy castoridae. Agencies do share data. They do it in a face-to-face sort of setup, generally in command posts and Emergency Operations Centers. You would be surprised how well the high-ups work together. Electronic datasharing, though, has numerous hurdles to overcome before it would be an effective tool to responding agencies, starting with the fact that the information we have is unreliable. For your example of building plans, unfortunately layouts are not reliable because they can and do change frequently, and generally nobody in government has one that is accurate. The best way to get accurate building plans is from the site manager. The most up-to-date site diagram for the building I am sitting in right now was just updated two years ago by the Assessment office, and it isn't even close to being correct. Among other things it shows an extra wing that won't even fit on the property. That is typical. Interior layouts change all the time, especially in Commercial spaces where the space is leased.
As far as that information being useful if it was accurate, I would say this: Incidents are handled in a heirarchial command structure. Let's say that your building is on fire. Each company responding will have orders to execute that are given to them by a command unit that is in charge of them at the time when the command is given (under NIMS and Unified Command the command structure is fluid as an incident changes). That company's order is generally specific (go in entrance "x", do "y" at position "z").
So to some extent the company might benefit from knowing the layout, but that benefit is severely limited. During the progression of an incident, frequently things "happen" to the interior of the structure. Walls are breached. Debris appears. Ceilings and walls collapse. The floorplan becomes a hazard if the company relies on it. However, Command can use the floorplan to move companies around and in case of an emergency inside where a crew becomes trapped, lost, or experiences some other emergency, can direct response units to approach in the most efficient manner.
So, I would prefer to keep this in Command or EOC.
Hey, Marc. Let's continue with the 9/11 example for a moment. Actually it is MORE efficient to have the communications separate in this type of situation. Much of law-enforcement traffic uses 10- codes. However, the rest of the communication is generally verbose and free-form by fire standards. Fire communication is generally very structured and tight by police standards. Where police communications tend to be more descriptive, fire communications tend to be more generic. (And if you really want to go to the extreme, you should listen to air traffic control frequencies). Even "mayday" calls are dramatically different between police and fire. There are very important reasons for these differences.
That is where NIMS and Unified Command comes into play. These programs and concepts provide an excellent framework for helping resolve the issues. They are handled at a high level, and the actual information and commands move up and down the chain as necessary. The interaction and translation happens off-line, so that the most limited resources at a major incident (namely radio bandwidth and a person's ability to monitor multiple conversations at once) are not compromised by the goal of getting a guy with a sledgehammer and a guy with an MP-5 to somehow mind meld.
In big incidents things are going to break down. Cops shouldn't be doing technical rescue. Firefighters shouldn't be doing crowd control. K9 SAR shouldn't be using their animals to threaten looters. Unfortunately at big incidents lines get blurred due to the immediate need. You can't fix that by jamming more people on the radio.
Um, maybe where you are things are different. We don't use 800 mhz, and we don't intend to. In addition, the reason why at least in our area HAM isn't usually figured into preplans is the same reason why other agencies are not, either. It is because our SOG's are for incidents directly within our jurisdiction. It is up to EMA to handle larger incidents, and to open one or more Emergency Operation Centers if the need arises, and unify command thusly. Amateur radio clubs do have a role to play, and at least in our area the Stormwatch and other clubs are on a contact list for EMA. You would not deal directly with me or my department under most circumstances. In a large incident, you would be assigned individually to various units, companies, or commands by the EOC to ensure that communications that were down are reestablished.
I'm sure you already know that (or we're just too sensible over here), but for the average observer reading this thread, their impression may be different.
If you have a complaint about how you are treated, take it up with EMA, not us. We're just the ones doing the detail work - you know - putting out fires, rescuing people off rooftops, etc.
The reason why it hasn't happened is that WE DON'T WANT IT OR SEE THE NEED FOR IT.
I do NOT want cops polluting my tactical channels with their blather. Do any of you own scanners? Take a listen to EMS, Fire, Law Enforcement, and Air Traffic channels. None of these groups want anybody else to contend with when the shit is hitting the fan. The vocabulary is different. The lingo is different. The culture is different. It's hard enough at an emergency scene to keep traffic to a minimum between the various commands, let alone adding several more channels that someone has to monitor, and shout over.
This is why NIMS and Unified Command exist. The various agencies can talk to each other IN PERSON since they're face-to-face, and then relay the messages via their radio frequencies to their people.
We don't want it. We don't need it. If you want to see how we operate in an emergency, ask to be an observer at the Command Post the next time your local jurisdiction does a mass-casualty drill. Airports do them on a grand scale once per year to once every two years. The regional Counterterrorism Task Forces do them once per year. Your regional Emergency Management Agency does it once per year. Watch and learn. We don't need more crap on the radio.
If you're the EFF, and you're looking to pick a fight, why would you pick THIS fight over THIS character?
The EFF is fighting for mindshare and clout among American households. So...they...choose...to...sue...to...uphold...some one's...right...to...mock...and...deride...a...bel oved...children's...character?!?!?!?! Why would you risk alienating families? There has got to be more than this than "We can be more ACLU than YOU"
This is nearly automatic, but it is only a stay of execution for EchoStar. Unless there was some horrible mistake made by the judge, it's only a matter of time, and only gives EchoStar the chance to negotiate with TiVo to either get bought or pay licensing rights. In the meantime, that giant sucking sound you year is EchoStar's revenue going out the window.
It's in interesting idea, but it also has the usual drawbacks, namely it is extremely difficult to move 200 feet of 2-1/2" for a team of firefighters when the line is charged - the weight is not the only problem. A charged line is stiff (ha, ha), so moving it arount corners, into rooms, up and down stairs, etc. is very awkward. You can't just drain a line every time you want to move it. It takes too long. So, you normally have to move a line while it's completely empty (called "flaking" the line), then charge it, or after it's charged, fight with the line the whole way. On top of all that, it's very easy to kink or even twist and decouple hose, which is, of course, disasterous. Normally what we do is carry as much line as we think we are going to need to a safe zone of the structure we're fighting, then flake it into big loops right there. That way we have all the hose we need in one place, and we can just extend into the hot zone without kinking, and also dragging the charged line the minimum distance to do the work we are going to do.
There is also the other problem: We typically charge our lines to the point where the nozzle-man's feet just leave the ground, then we ease back so they are just barely on the ground. This maximizes our flow into the area we are fighting. With a two-person nozzle team that means we have in the neighborhood of 600-700 lbs of ballast to offset the reaction force at the tip (the force of the water exiting the nozzle that is pushing back on it, which would result in the hose flying all over the place otherwise). (The 600-700 lbs is the weight of two firefighters, their bunker gear, air packs, etc.). The robot only weights 70kg, so it won't have nearly the control of the tip, which means that you can't push nearly the water.
I could see this as a good application when trying to work in a warehouse or supermarket, where the distance from the door is large. However, the device is going to need assistance to move a great distance since the line has to be charged in order for it to function, but if the line is charged it becomes much harder to move the line. That combination seems to defeat the purpose - of keeping firefighters out of harm's way.
Personally I'm in favor of our current option "b" - trench cut the roof (long cut perpendicular to the path of the fire, in an area we know is good), then drown the cut with water from a ladder pipe, which causes a water curtain - the good part of the building is saved by the water curtain, which means we can fight the remainder from a position of strength.
Here's the problem with adopting Open Source for everything: It completely homogenizes the entire process of software development, which means that it tends to quash alternative development tools, languages, and techniques.
For example, is it good or bad that JavaScript has implicit typing? Many developers want explicit typing, and call implicit typing "lazy". I can barely have a conversation with a group of fellow geeks without getting shouted down on this topic. The problem with group-anything is that group-think will prevail. To quote one of my favorite posters from demotivators.com, "Meetings: None of us is as dumb as all of us".
In addition, alternative lanuages and tools tend to be stifled in so-called "open" (read group) environments, because the rest of the group immediately pushes to have the alternative tool or environment removed, unless the group agrees that it is a good idea. Is that the way inventions are made? No. Inventions are made by a single person with a radical idea avoiding all the intervention/interference, naysayers, etc. and presenting that idea DESPITE the opinions of others. I can see opening source after the fact for auditing and sugestions, but not for development.
It seems that a lot of the open source push has been a reaction to the fact that many of the development tools we use are not at a high enough level of abstraction. If you abstract away from code and languages where you are doing your own memory management, one would think that you would experience fewer memory-related programming issues. What kind of issues are most often discussed with open-source development? Exploits, buffer overflows, etc. I can see the database engine being open source, which would help with dealing with injection attacks, but the rest of the application (where the money is) can't possibly benefit from having lots of people "helping out".
Imagine the entire cast of The Food Network making soup together at the same time. "None of us is as dumb as all of us".
I understand the whole real-world-metaphor drawback. I think that we're missing the point - that this is an excellent transitional tool to a paperless work area.
Part of what we all are failing to consider here is that we need desktop managers because the desktops on our copmputers are comparatively small to the desktops we actually work at in the real world, due to screen resolution restrictions vs. our ability to see things that are small. Face it. We are taking a 48" x 30-36" desk and trying to compress it onto a 17", 19", 21", 30" monitor IN MOST CASES. I know that most of us as geeks probably have two or three monitors on our desks, but if you compare that screen space relative to your real desk, it's like trying to run your office life off an end-table in your living room.
The problem isn't that computers can't replace paper, the problem is that we don't have the number of pixels for the average user to make that proposition appetizing to the average user. Everything we can do to improve that situation makes the dream of going paperless more reachable.
If Mass. can deploy OO.o or other office tools for free, then the value of M$'s office tools to those same institutions is...essentially nothing. So what we are finding is that M$ is giving away software that is being given away by others anyhow. Granted OO.o isn't the same thing, doesn't have the same shine or finish to it, and is probably several years behind M$ in terms of features, but I am willing to bet that the vast majority of schools and schoolkids won't notice the difference.
Heck, I use office products all day every day, on one machine that has M$ office, and one that has OO.o and I can't say that I have noticed a significant difference in terms of my productivity, either.
For those of you who play G.R.A.W. (Ghost Recon Advanced Warfighter), you know how to take care of that pesky drone problem...just grab your assault rifle, set it on full-auto, and blast away until the drone is a million tiny pieces...then wait two minutes for the next one to appear behind the blue spawn (I'm assuming that's the team the cops would be).
Hopefully nobody will take this too literally and start base-raping the boys in blue, though. Or better yet, grab your ZEUS anti-tank missile, and take that thing out the overkill way. Mmm!
We already know that Morfik and GWT support all of these features, but does Script# or Atlas, yet? I didn't think so, but my memory may be faulty.
Even more importantly than knowing how to support is not having to know how to support it. Thankfully AJAX is advancing so quickly that articles like this are going to be less and less relevant since more and more tools will just implement the features right out of the box.
Wasn't there just an article on/. yesterday that said that the next gen chips kick AMD's ass? Didn't that same article say that AMD's worst nightmare was coming true? I'm all confused now.
I checked out the article, and the examples, and I'm impressed. Unfortunately this is the same method used in climate modeling, economic forecasting, genetic engineering, and human drug trials. Did you check out the original article? Were those studies cited put just in a straight table for illustration, or were they tabulated first in...a spreadsheet? I have to say, though, that some of the studies are rather dated, and the data isn't all similar. However, the example of "whoops"'s that people have run into were frightening, and those were just financial spreadsheets. I guess that just goes to show you that spreadsheets are good modeling tools, but they shouldn't be in the hands of everyone in the office preparing the reports. Instead the IT department should be writing permanent applications to make the computations, so then at least it's harder to make changes, so it's harder to accidentally replace a value in a cell or a formula that ultimately costs you $1 billion or so...
So...a game bitch complains that Apple doesn't push games, and the title says that Apple has to push games? WHAT? Who edits these things? Maybe Apple cares about gaming the same way Red Hat does...not at all.
Well, it's good that many of you are so predictable. You have once again commented on something that you haven't even done the most basic research on in order to get a post listed sooner and mod-troll.
So here goes:
1) Morfik is an IDE/RAD tool with a built-in PDF report writer, built-in web server (Apache) and built-in database (Firebird). The other tools to this point don't have any of these features.
2) Morfik allows you to write the code of your application using Java, C#, BASIC, or Object Pascal (client side or server side). You can also mix and match syntaxes to achieve whatever your goal is. It supports state-control, including the forward, back, and reload buttons, bookmarking, etc. so it doesn't break the functionality of your browser. GWT has Java support, and I believe supports state control, but I don't believe does it natively with a database, but I've only been playing with GWT since the public release, so I'm not 100% on this.
3) When Morfik was first featured on Slashdot a mere six months ago, it was met with skepticism and rancor. Now that Google has released GWT the/. tide has turned - apparently now that someone else has released a tool with a subset of the same features, it's obvious and uninteresting. Which is it? What a difference six months makes.
4) The issue isn't the release date of GWT vs. when they got a gander at Morfik. The issue is the start date of work on GWT, or Atlas, or whatever tool you're worried about vs. the date of the Patent application that everyone is complaining about, and the dates of the relevant documents that are cited in the application. Has anybody bothered to look either one up yet? Let's hypothetically say that the patent application was dated in March 2004. Now what? What about how all of this relates to Microsoft's progress on Atlas, or any of the other tools that are suddenly in development to build AJAX apps?
5) I don't see any of you asking what the relevant portions of the patent application are compared to the relevant features of GWT. Aren't these last two questions the ones that are really going to matter?
Worst. Kept. Secret. Ever. Morfik builds AJAX RAD IDE. Google releases AJAX RAD IDE. Morfik uses a "compiler" to take Java and turn it into JavaScript, CSS, DHTML, etc. Google releases "compiler" to take Java and turn it into JavaScrip, CSS, DHTML, etc.
I'm SOOOOOOOOOOOOOOOOO surprised. It was nice to see that these two companies finally teamed up to get this into the hands of the masses. Good job!
What do you mean there is nothing on them? Look at the pictures, morons. You might be able to argue that they are fabricated, but maybe you would like to explain what that big round thing that's entering the building, and the other angle showing what appears to be an airplane? Well, the "big round thing" could be an emu, but I'm a little suspicious...
One of the things you have to understand is the way that they are measuring spam vs. non-spam. I decided to try out this project today, and some messages that I would consider to be SPAM (i.e. UCE) are not identified by the spam filter as such, and looking at the raw message doesn't appear to contain any attempt to deceive. So, it is unclear from the project what exactly they consider to be spam, and it's impossible for me to tell if they had an EBR (uh, that's existing business relationship) with the emailer, which reduces me to reviewing the message and trying to determine if it's UCE or if any of the crap inside of it is forged or not, and from that perspective determining if it is SPAM.
This is hardly ideal. I understand that what they're asking is for me to not mimic the spam filter but to be the spam filter for this mailbox, but now that I've done it for a dozen or so messages I understand how hard it is for spam filters to implement a hard-and-fast set of rules for determining what is and what is not spam. Who knows? Maybe that p3n15 enlargement email was legit, you pr0n-sicko
Morfik http://www.morfik.com/ has already worked on these issues and deal with them so you don't have to lift a finger when you build your application. Atlas is (reportedly) going to (eventually) make all of these issues go away as well. Since Atlas isn't handling these issues yet I can't comment on how elegant it is, but Morfik is unbelievable. States are just handled. Bookmarks, back, forward, and reload buttons are no longer an issue. What's even cooler about Atlas and Morfik is that they are RAD IDE's with built-in everything that you need. Obviously Atlas is an all Microsoft tool, but Morfik integrates the more/.-friendly Apache and Firebird servers, which also means that in theory you shouldn't be burdened with a higher deployment cost. How they're going to handle patches to those products as new versions come out hasn't been determined, AFAIK.
Both make the transition to AJAX development even easier since the code-portion of your application is built in a high-level language you are already familiar with, whether or not you do web-development for a living already.
Slashdot Mirror
MDK was also a Shiny game, and it was the first pseudo-realistic sniper-shooter that I can recall. What a blast.
Unfortunately, this has absolutely no chance of success. Motions for Summary Judgment are generally denied unless the other side's argument is so flimsy that there is no shot at it succeeding at trial, and is wasting the court's time. However, since a judge can't just dismiss a civil action for being st00pid, s/he generally first tries to get the parties to settle, and then tries to encourage the plaintiff (or defendant) to punt, to save them the embarrassment of granting a MSJ. If they refuse, then this might succeed.
In a case like this, though, where the facts and evidence are sure to be the crux of matters, there is no way the judge will grant it, which is unfortunate.
When the new high-power sonar systems were being tested, they asked for SCUBA divers to participate. This was at a certain test location that is literally out in the middle of the ocean. It wasn't like they took you out there. You were either already there or you weren't. Among other things, the time that divers were in the water, and the exact spot were requested, along with personal experiences and observations of what the "wildlife" was doing. Since the location is a remote base, they were pretty confident that the reports were reasonable.
Howdy castoridae. Agencies do share data. They do it in a face-to-face sort of setup, generally in command posts and Emergency Operations Centers. You would be surprised how well the high-ups work together. Electronic datasharing, though, has numerous hurdles to overcome before it would be an effective tool to responding agencies, starting with the fact that the information we have is unreliable. For your example of building plans, unfortunately layouts are not reliable because they can and do change frequently, and generally nobody in government has one that is accurate. The best way to get accurate building plans is from the site manager. The most up-to-date site diagram for the building I am sitting in right now was just updated two years ago by the Assessment office, and it isn't even close to being correct. Among other things it shows an extra wing that won't even fit on the property. That is typical. Interior layouts change all the time, especially in Commercial spaces where the space is leased.
As far as that information being useful if it was accurate, I would say this: Incidents are handled in a heirarchial command structure. Let's say that your building is on fire. Each company responding will have orders to execute that are given to them by a command unit that is in charge of them at the time when the command is given (under NIMS and Unified Command the command structure is fluid as an incident changes). That company's order is generally specific (go in entrance "x", do "y" at position "z").
So to some extent the company might benefit from knowing the layout, but that benefit is severely limited. During the progression of an incident, frequently things "happen" to the interior of the structure. Walls are breached. Debris appears. Ceilings and walls collapse. The floorplan becomes a hazard if the company relies on it. However, Command can use the floorplan to move companies around and in case of an emergency inside where a crew becomes trapped, lost, or experiences some other emergency, can direct response units to approach in the most efficient manner.
So, I would prefer to keep this in Command or EOC.
Hey, Marc. Let's continue with the 9/11 example for a moment. Actually it is MORE efficient to have the communications separate in this type of situation. Much of law-enforcement traffic uses 10- codes. However, the rest of the communication is generally verbose and free-form by fire standards. Fire communication is generally very structured and tight by police standards. Where police communications tend to be more descriptive, fire communications tend to be more generic. (And if you really want to go to the extreme, you should listen to air traffic control frequencies). Even "mayday" calls are dramatically different between police and fire. There are very important reasons for these differences.
That is where NIMS and Unified Command comes into play. These programs and concepts provide an excellent framework for helping resolve the issues. They are handled at a high level, and the actual information and commands move up and down the chain as necessary. The interaction and translation happens off-line, so that the most limited resources at a major incident (namely radio bandwidth and a person's ability to monitor multiple conversations at once) are not compromised by the goal of getting a guy with a sledgehammer and a guy with an MP-5 to somehow mind meld.
In big incidents things are going to break down. Cops shouldn't be doing technical rescue. Firefighters shouldn't be doing crowd control. K9 SAR shouldn't be using their animals to threaten looters. Unfortunately at big incidents lines get blurred due to the immediate need. You can't fix that by jamming more people on the radio.
Um, maybe where you are things are different. We don't use 800 mhz, and we don't intend to. In addition, the reason why at least in our area HAM isn't usually figured into preplans is the same reason why other agencies are not, either. It is because our SOG's are for incidents directly within our jurisdiction. It is up to EMA to handle larger incidents, and to open one or more Emergency Operation Centers if the need arises, and unify command thusly. Amateur radio clubs do have a role to play, and at least in our area the Stormwatch and other clubs are on a contact list for EMA. You would not deal directly with me or my department under most circumstances. In a large incident, you would be assigned individually to various units, companies, or commands by the EOC to ensure that communications that were down are reestablished.
I'm sure you already know that (or we're just too sensible over here), but for the average observer reading this thread, their impression may be different.
If you have a complaint about how you are treated, take it up with EMA, not us. We're just the ones doing the detail work - you know - putting out fires, rescuing people off rooftops, etc.
The reason why it hasn't happened is that WE DON'T WANT IT OR SEE THE NEED FOR IT.
I do NOT want cops polluting my tactical channels with their blather. Do any of you own scanners? Take a listen to EMS, Fire, Law Enforcement, and Air Traffic channels. None of these groups want anybody else to contend with when the shit is hitting the fan. The vocabulary is different. The lingo is different. The culture is different. It's hard enough at an emergency scene to keep traffic to a minimum between the various commands, let alone adding several more channels that someone has to monitor, and shout over.
This is why NIMS and Unified Command exist. The various agencies can talk to each other IN PERSON since they're face-to-face, and then relay the messages via their radio frequencies to their people.
We don't want it. We don't need it. If you want to see how we operate in an emergency, ask to be an observer at the Command Post the next time your local jurisdiction does a mass-casualty drill. Airports do them on a grand scale once per year to once every two years. The regional Counterterrorism Task Forces do them once per year. Your regional Emergency Management Agency does it once per year. Watch and learn. We don't need more crap on the radio.
If you're the EFF, and you're looking to pick a fight, why would you pick THIS fight over THIS character?
e one's...right...to...mock...and...deride...a...bel oved...children's...character?!?!?!?! Why would you risk alienating families? There has got to be more than this than "We can be more ACLU than YOU"
The EFF is fighting for mindshare and clout among American households. So...they...choose...to...sue...to...uphold...som
This is nearly automatic, but it is only a stay of execution for EchoStar. Unless there was some horrible mistake made by the judge, it's only a matter of time, and only gives EchoStar the chance to negotiate with TiVo to either get bought or pay licensing rights. In the meantime, that giant sucking sound you year is EchoStar's revenue going out the window.
It's in interesting idea, but it also has the usual drawbacks, namely it is extremely difficult to move 200 feet of 2-1/2" for a team of firefighters when the line is charged - the weight is not the only problem. A charged line is stiff (ha, ha), so moving it arount corners, into rooms, up and down stairs, etc. is very awkward. You can't just drain a line every time you want to move it. It takes too long. So, you normally have to move a line while it's completely empty (called "flaking" the line), then charge it, or after it's charged, fight with the line the whole way. On top of all that, it's very easy to kink or even twist and decouple hose, which is, of course, disasterous. Normally what we do is carry as much line as we think we are going to need to a safe zone of the structure we're fighting, then flake it into big loops right there. That way we have all the hose we need in one place, and we can just extend into the hot zone without kinking, and also dragging the charged line the minimum distance to do the work we are going to do.
There is also the other problem: We typically charge our lines to the point where the nozzle-man's feet just leave the ground, then we ease back so they are just barely on the ground. This maximizes our flow into the area we are fighting. With a two-person nozzle team that means we have in the neighborhood of 600-700 lbs of ballast to offset the reaction force at the tip (the force of the water exiting the nozzle that is pushing back on it, which would result in the hose flying all over the place otherwise). (The 600-700 lbs is the weight of two firefighters, their bunker gear, air packs, etc.). The robot only weights 70kg, so it won't have nearly the control of the tip, which means that you can't push nearly the water.
I could see this as a good application when trying to work in a warehouse or supermarket, where the distance from the door is large. However, the device is going to need assistance to move a great distance since the line has to be charged in order for it to function, but if the line is charged it becomes much harder to move the line. That combination seems to defeat the purpose - of keeping firefighters out of harm's way.
Personally I'm in favor of our current option "b" - trench cut the roof (long cut perpendicular to the path of the fire, in an area we know is good), then drown the cut with water from a ladder pipe, which causes a water curtain - the good part of the building is saved by the water curtain, which means we can fight the remainder from a position of strength.
Here's the problem with adopting Open Source for everything: It completely homogenizes the entire process of software development, which means that it tends to quash alternative development tools, languages, and techniques.
For example, is it good or bad that JavaScript has implicit typing? Many developers want explicit typing, and call implicit typing "lazy". I can barely have a conversation with a group of fellow geeks without getting shouted down on this topic. The problem with group-anything is that group-think will prevail. To quote one of my favorite posters from demotivators.com, "Meetings: None of us is as dumb as all of us".
In addition, alternative lanuages and tools tend to be stifled in so-called "open" (read group) environments, because the rest of the group immediately pushes to have the alternative tool or environment removed, unless the group agrees that it is a good idea. Is that the way inventions are made? No. Inventions are made by a single person with a radical idea avoiding all the intervention/interference, naysayers, etc. and presenting that idea DESPITE the opinions of others. I can see opening source after the fact for auditing and sugestions, but not for development.
It seems that a lot of the open source push has been a reaction to the fact that many of the development tools we use are not at a high enough level of abstraction. If you abstract away from code and languages where you are doing your own memory management, one would think that you would experience fewer memory-related programming issues. What kind of issues are most often discussed with open-source development? Exploits, buffer overflows, etc. I can see the database engine being open source, which would help with dealing with injection attacks, but the rest of the application (where the money is) can't possibly benefit from having lots of people "helping out".
Imagine the entire cast of The Food Network making soup together at the same time. "None of us is as dumb as all of us".
I understand the whole real-world-metaphor drawback. I think that we're missing the point - that this is an excellent transitional tool to a paperless work area.
Part of what we all are failing to consider here is that we need desktop managers because the desktops on our copmputers are comparatively small to the desktops we actually work at in the real world, due to screen resolution restrictions vs. our ability to see things that are small. Face it. We are taking a 48" x 30-36" desk and trying to compress it onto a 17", 19", 21", 30" monitor IN MOST CASES. I know that most of us as geeks probably have two or three monitors on our desks, but if you compare that screen space relative to your real desk, it's like trying to run your office life off an end-table in your living room.
The problem isn't that computers can't replace paper, the problem is that we don't have the number of pixels for the average user to make that proposition appetizing to the average user. Everything we can do to improve that situation makes the dream of going paperless more reachable.
If Mass. can deploy OO.o or other office tools for free, then the value of M$'s office tools to those same institutions is...essentially nothing. So what we are finding is that M$ is giving away software that is being given away by others anyhow. Granted OO.o isn't the same thing, doesn't have the same shine or finish to it, and is probably several years behind M$ in terms of features, but I am willing to bet that the vast majority of schools and schoolkids won't notice the difference.
Heck, I use office products all day every day, on one machine that has M$ office, and one that has OO.o and I can't say that I have noticed a significant difference in terms of my productivity, either.
For those of you who play G.R.A.W. (Ghost Recon Advanced Warfighter), you know how to take care of that pesky drone problem...just grab your assault rifle, set it on full-auto, and blast away until the drone is a million tiny pieces...then wait two minutes for the next one to appear behind the blue spawn (I'm assuming that's the team the cops would be).
Hopefully nobody will take this too literally and start base-raping the boys in blue, though. Or better yet, grab your ZEUS anti-tank missile, and take that thing out the overkill way. Mmm!
We already know that Morfik and GWT support all of these features, but does Script# or Atlas, yet? I didn't think so, but my memory may be faulty. Even more importantly than knowing how to support is not having to know how to support it. Thankfully AJAX is advancing so quickly that articles like this are going to be less and less relevant since more and more tools will just implement the features right out of the box.
Wasn't there just an article on /. yesterday that said that the next gen chips kick AMD's ass? Didn't that same article say that AMD's worst nightmare was coming true? I'm all confused now.
I checked out the article, and the examples, and I'm impressed. Unfortunately this is the same method used in climate modeling, economic forecasting, genetic engineering, and human drug trials.
Did you check out the original article? Were those studies cited put just in a straight table for illustration, or were they tabulated first in...a spreadsheet?
I have to say, though, that some of the studies are rather dated, and the data isn't all similar. However, the example of "whoops"'s that people have run into were frightening, and those were just financial spreadsheets.
I guess that just goes to show you that spreadsheets are good modeling tools, but they shouldn't be in the hands of everyone in the office preparing the reports. Instead the IT department should be writing permanent applications to make the computations, so then at least it's harder to make changes, so it's harder to accidentally replace a value in a cell or a formula that ultimately costs you $1 billion or so...
So...a game bitch complains that Apple doesn't push games, and the title says that Apple has to push games? WHAT? Who edits these things? Maybe Apple cares about gaming the same way Red Hat does...not at all.
I'd just like a couple of Jessica Simpson nude pinups...please.
Well, it's good that many of you are so predictable. You have once again commented on something that you haven't even done the most basic research on in order to get a post listed sooner and mod-troll. So here goes: 1) Morfik is an IDE/RAD tool with a built-in PDF report writer, built-in web server (Apache) and built-in database (Firebird). The other tools to this point don't have any of these features. 2) Morfik allows you to write the code of your application using Java, C#, BASIC, or Object Pascal (client side or server side). You can also mix and match syntaxes to achieve whatever your goal is. It supports state-control, including the forward, back, and reload buttons, bookmarking, etc. so it doesn't break the functionality of your browser. GWT has Java support, and I believe supports state control, but I don't believe does it natively with a database, but I've only been playing with GWT since the public release, so I'm not 100% on this. 3) When Morfik was first featured on Slashdot a mere six months ago, it was met with skepticism and rancor. Now that Google has released GWT the /. tide has turned - apparently now that someone else has released a tool with a subset of the same features, it's obvious and uninteresting. Which is it? What a difference six months makes.
4) The issue isn't the release date of GWT vs. when they got a gander at Morfik. The issue is the start date of work on GWT, or Atlas, or whatever tool you're worried about vs. the date of the Patent application that everyone is complaining about, and the dates of the relevant documents that are cited in the application. Has anybody bothered to look either one up yet? Let's hypothetically say that the patent application was dated in March 2004. Now what? What about how all of this relates to Microsoft's progress on Atlas, or any of the other tools that are suddenly in development to build AJAX apps?
5) I don't see any of you asking what the relevant portions of the patent application are compared to the relevant features of GWT. Aren't these last two questions the ones that are really going to matter?
Worst. Kept. Secret. Ever. Morfik builds AJAX RAD IDE. Google releases AJAX RAD IDE. Morfik uses a "compiler" to take Java and turn it into JavaScript, CSS, DHTML, etc. Google releases "compiler" to take Java and turn it into JavaScrip, CSS, DHTML, etc.
I'm SOOOOOOOOOOOOOOOOO surprised. It was nice to see that these two companies finally teamed up to get this into the hands of the masses. Good job!
What do you mean there is nothing on them? Look at the pictures, morons. You might be able to argue that they are fabricated, but maybe you would like to explain what that big round thing that's entering the building, and the other angle showing what appears to be an airplane? Well, the "big round thing" could be an emu, but I'm a little suspicious...
One of the things you have to understand is the way that they are measuring spam vs. non-spam. I decided to try out this project today, and some messages that I would consider to be SPAM (i.e. UCE) are not identified by the spam filter as such, and looking at the raw message doesn't appear to contain any attempt to deceive. So, it is unclear from the project what exactly they consider to be spam, and it's impossible for me to tell if they had an EBR (uh, that's existing business relationship) with the emailer, which reduces me to reviewing the message and trying to determine if it's UCE or if any of the crap inside of it is forged or not, and from that perspective determining if it is SPAM.
This is hardly ideal. I understand that what they're asking is for me to not mimic the spam filter but to be the spam filter for this mailbox, but now that I've done it for a dozen or so messages I understand how hard it is for spam filters to implement a hard-and-fast set of rules for determining what is and what is not spam. Who knows? Maybe that p3n15 enlargement email was legit, you pr0n-sicko
I believe there is a compatibility issue in Safari. Of course it's also only in an EARLY beta. I don't remember about Opera.
Morfik http://www.morfik.com/ has already worked on these issues and deal with them so you don't have to lift a finger when you build your application. Atlas is (reportedly) going to (eventually) make all of these issues go away as well. Since Atlas isn't handling these issues yet I can't comment on how elegant it is, but Morfik is unbelievable. States are just handled. Bookmarks, back, forward, and reload buttons are no longer an issue. What's even cooler about Atlas and Morfik is that they are RAD IDE's with built-in everything that you need. Obviously Atlas is an all Microsoft tool, but Morfik integrates the more /.-friendly Apache and Firebird servers, which also means that in theory you shouldn't be burdened with a higher deployment cost. How they're going to handle patches to those products as new versions come out hasn't been determined, AFAIK.
Both make the transition to AJAX development even easier since the code-portion of your application is built in a high-level language you are already familiar with, whether or not you do web-development for a living already.
It's so cool to live in interesting times!