Wa actually do move in space when we walk. We move from one point to another. In the cosmologic time (billions of terrestial years) the space expanding is a phenomenon that is very real but very slow at the moment (expansion is slowing down).
this is often compared to a baking cake with raisins inside. When you start baking the dough is dense and the resins are close together. As the dough rises, it expands and the raisins move further apart. Their position with respect to the dough is still the same but they are further apart. Now in terms of the universe, the space itself is the dough. Now if you imagine a bug that got stuck in your dough (yuck!) which starts crawling and eating the resins, that bug has to cover more and more distance to get to the next resin as the dough keeps growing. When we walk around we are like that hypothetical bug. We can move in space but we can't really see it expanding even though it does expand all the time albeit very slowly.
This is pretty hard to wrap your head around it but it's the simplest (correct) explanation of expanding universe that I've heard.
Expansion of the universe is not a physical movement through space. It is a rate of change of the physical properties of space ie. space is stretching or to be more precise, light shifts more to the red as it travels now than it did fifteen billion years ago.
Big bang was not really an explosion per se. In fact all the matter in the universe has not changed its position since the beginning of the universe. Instead it's space itself that got "stretched" ie. the time for light to reach two distinct points in the universe has increased over the last fifteen billion years. The escape of galaxies works the same way.
There was no big cluster of mass that exploded like a bomb. It is simply that space itself expanded, meaning that the shift to the red has increased for the light travelling between two disctinct points in the universe.
For me it's custom tags mostly. But separating the form bean and the action I find annoying. But the custom tags do seem to cut down on the size of the jsp pages, so I put up with it. But I agree, struts should have been a hell of a lot simpler. I'm investigating webwork2 which some people seem to swear by these days. I'm going to check out what the fuss is all about.
Spring seems to be touted a lot lately. What are its selling points? I'd like to investigate it a bit more but I'm not sure what its "killer feature" is. Do they offer custom tags the way struts does?
Yeah, you're right. Probably systems that require distributed transactions with the full 2-pc are the ones that are suitable candidates for EJB development. For just about everything else it's an overkill.
Is EJB dying?
on
Bitter EJB
·
· Score: 5, Informative
You don't have to be a Kreskin... blah, blah.
That's how every good slashdot troll should begin. But if there is one technology that is currently at real risk of extinction in the Java world it is EJB.
Almost every new J2EE project that I hear about steers clear from EJB towards simpler solutions such as plain servlet/jsp with JDO for persistence. Then you scale it horizontally through mod_jk or a hardware load balancer. No need for confusing (and restrictive) enterprise beans.
Entity EJBs have been critisized many times and rigtfully so. Session beans I find are OK but for me (and my company) it's a case of "I really don't need them given the baggage of complexity and the restrictive nature of their API.
Message driven beans are probably worthy of consideration but there isn't that much to them really. Certainly not something you couldn't implement on your own with plain JMS. I've done it, didn't take much time and it worked just as well as the specc'ed MDBs. And I don't have to run within an EJB container. I can deploy to Tomcat and have SonicMQ running remotely.
Is EJB going to really take off? Seems that the spec was vastly improved but not all problems with the technology have been addressed and then there is the phsycological issue for many developers who had nasty experiences with EJB 1.1 development.
I won't trash EJB they are a certain way to develop enterprise applications. I just find that I end up with much simpler design if I avoid them in lieu of something simpler. My preferred stack at the moment (assuming no legacy systems to integrate with) is as follows:
Tell me about it. In the past five years I worked for two companies. One with no patents, no NDA's, half page employment contract and excellent product.
The other full of secrecy, NDA slapped on everybody, everywhere. 14 page employment contract and hyper-ego management.
Guess which one is still in business...
The difference I think lies in the fact that the first company was based in the UK while the second in the USA. The first had an awesome innovative product that customers wanted while the second had a silly dotcom-like fluffy idea that nobody wanted to buy into. Yet they wouldn't even tell you in the interview what that idea was. Funny how that works.
In fact, they must be shitting their pants. McBride's an asshole - the only thing that comes out of him is shit.
This Comment was generated with the Comment-O-Matic for SCO Stories.
How do you effectively query that thing? OO links are not efficient to follow unless you set up hashmaps all over the place which would make your object model absolutely horrible to maintain...
Maybe we don't really need a better match between OO and RDBMS? If OO has such a strong impedance mismatch with Relational technology perhaps it's OO that is really flawed and not RDBMS?
It once struck me that one could hypothetically develop a language that is table based. Not a language that is table friendly but a language that is built on tables. Sort of like Lisp treats everything as a list this language would treat everything as tables and have a built in capability to evaluate and modify tables. Of course every table 'eval' would return another table that could be 'evaled' just like lists in lisp.
Maybe such a language is not practical for a variety of reasons but it certainly would suffer no impedance mismatch with an RDBMS. As a matter of fact its runt time would be an RDBMS.
Silly? Maybe. But I think everyone who's worked on enterprise OO application has this feeling that something between these two just doesn't click. Right now, for a java developer at least, the least painful option seems to be Hibernate. Great implementation even if the whole paradigm is flawed:)
OK. I'm off my rocker here. However, I've found this explanation which to my (untrained) eye looks like a very plausible theory. It argues that upon reunion no time shift will have ocurred between the travellers.
Obviously this is the twins paradox with a twist. I know that the prevailing notion has to do with the shrinkage of space but I find the explanation in the link above much more compelling.
Velocity is always relative. There is no single "middle of the universe" so every speed is relative. If the second spacecraft is stationary relative to earth, then its clock will run at the same speed as a terrestial clock.
You're getting into trouble because you're assuming that time is constant. In practice time is a function of velocity. There is no absolute 19:00GMT.
If you board a hypothetical spacecraft right which can travel at say, 0.9c so you'll get to jupiter in time to watch the event. If you take your stopwatch with you you'll see that only a few minutses went by since you boarded the spacecraft. However for the rest of us an hour will have passed since you left. It doesn't quite make sense to say that the crash will happen at 19:00GMT. For us it will happen then, but we will find out about it an hour later (20:00GMT) because that's when the light wil l get to us. For you, the hypothetical astronaut the event will have occured at 19:10GMT.
What if it finds a monolith there? What then? Has anyone thought about this?
Re:Does this work for non native speakers?
on
Can You Raed Tihs?
·
· Score: 1
English is my second language and I read it without any problems. I think it is purely a matter of your language proficiency. Non natives can definitely read and understand this.
Doesn't look like eclipse at all! Eclipse uses SWT which wraps native system widgets. This stuff uses Swing. It's really apparent if you look at the scrollbars.
Re:Indemnity from IP infringement
on
Back To SCO
·
· Score: 1
Well, specifically exclude the cost of the media in the "indemnity contract" and Linus is liable for exactly $0. He's still assuming liability it's just that he's liable for the cost of GPL software less the media it's distributed on:)
Re:File a complaint with the FTC
on
Back To SCO
·
· Score: 1
done
Indemnity from IP infringement
on
Back To SCO
·
· Score: 4, Insightful
There is a very interesting factoid with regards to the IP indemnity issue that SCO likes to bring up that Eric and Bruce mention in this article:
"...the warranties and indemnities offered by SCO and others such as Microsoft are carefully worded so that the vendor's liability is limited to the software purchase price, They thus offer no actual shield against liability claims or damages. "
Don't know about the rest of slashdot but I was not aware of this particular string.
Actually I don't see why most GPL developers couldn't offer the exact same type of indemnity: refund on the purchase price in case there are IP violations. I think they should do it just to see SCO's reaction to it. Should be quite hillarious.
this is often compared to a baking cake with raisins inside. When you start baking the dough is dense and the resins are close together. As the dough rises, it expands and the raisins move further apart. Their position with respect to the dough is still the same but they are further apart. Now in terms of the universe, the space itself is the dough. Now if you imagine a bug that got stuck in your dough (yuck!) which starts crawling and eating the resins, that bug has to cover more and more distance to get to the next resin as the dough keeps growing. When we walk around we are like that hypothetical bug. We can move in space but we can't really see it expanding even though it does expand all the time albeit very slowly.
This is pretty hard to wrap your head around it but it's the simplest (correct) explanation of expanding universe that I've heard.
Expansion of the universe is not a physical movement through space. It is a rate of change of the physical properties of space ie. space is stretching or to be more precise, light shifts more to the red as it travels now than it did fifteen billion years ago.
There was no big cluster of mass that exploded like a bomb. It is simply that space itself expanded, meaning that the shift to the red has increased for the light travelling between two disctinct points in the universe.
For me it's custom tags mostly. But separating the form bean and the action I find annoying. But the custom tags do seem to cut down on the size of the jsp pages, so I put up with it. But I agree, struts should have been a hell of a lot simpler. I'm investigating webwork2 which some people seem to swear by these days. I'm going to check out what the fuss is all about.
Spring seems to be touted a lot lately. What are its selling points? I'd like to investigate it a bit more but I'm not sure what its "killer feature" is. Do they offer custom tags the way struts does?
Yeah, you're right. Probably systems that require distributed transactions with the full 2-pc are the ones that are suitable candidates for EJB development. For just about everything else it's an overkill.
That's how every good slashdot troll should begin. But if there is one technology that is currently at real risk of extinction in the Java world it is EJB. Almost every new J2EE project that I hear about steers clear from EJB towards simpler solutions such as plain servlet/jsp with JDO for persistence. Then you scale it horizontally through mod_jk or a hardware load balancer. No need for confusing (and restrictive) enterprise beans.
Entity EJBs have been critisized many times and rigtfully so. Session beans I find are OK but for me (and my company) it's a case of "I really don't need them given the baggage of complexity and the restrictive nature of their API.
Message driven beans are probably worthy of consideration but there isn't that much to them really. Certainly not something you couldn't implement on your own with plain JMS. I've done it, didn't take much time and it worked just as well as the specc'ed MDBs. And I don't have to run within an EJB container. I can deploy to Tomcat and have SonicMQ running remotely.
Is EJB going to really take off? Seems that the spec was vastly improved but not all problems with the technology have been addressed and then there is the phsycological issue for many developers who had nasty experiences with EJB 1.1 development.
I won't trash EJB they are a certain way to develop enterprise applications. I just find that I end up with much simpler design if I avoid them in lieu of something simpler. My preferred stack at the moment (assuming no legacy systems to integrate with) is as follows:
- Struts
- Hibernate
- GLUE
- Tomcat
- JDOM
- SonicMQ if I need messaging
- Good DBMS
And I'm good to go. Look Ma, no EJB!yes but look at an average American city compared to an average British one. Where would you rather live?
The other full of secrecy, NDA slapped on everybody, everywhere. 14 page employment contract and hyper-ego management.
Guess which one is still in business...
The difference I think lies in the fact that the first company was based in the UK while the second in the USA. The first had an awesome innovative product that customers wanted while the second had a silly dotcom-like fluffy idea that nobody wanted to buy into. Yet they wouldn't even tell you in the interview what that idea was. Funny how that works.
In fact, they must be shitting their pants. McBride's an asshole - the only thing that comes out of him is shit. This Comment was generated with the Comment-O-Matic for SCO Stories.
Brits stole our Enigma credit, the French took Maria Sklodowska-Curie so at least let us keep our good ole RPN.
Why would CLOS be easier to use with a RDBMS than Java? That's a very strong statement. Please explain.
How do you effectively query that thing? OO links are not efficient to follow unless you set up hashmaps all over the place which would make your object model absolutely horrible to maintain...
The snapshot is made on a backup server. RTFW (Read the F**endly Website).
It once struck me that one could hypothetically develop a language that is table based. Not a language that is table friendly but a language that is built on tables. Sort of like Lisp treats everything as a list this language would treat everything as tables and have a built in capability to evaluate and modify tables. Of course every table 'eval' would return another table that could be 'evaled' just like lists in lisp.
Maybe such a language is not practical for a variety of reasons but it certainly would suffer no impedance mismatch with an RDBMS. As a matter of fact its runt time would be an RDBMS.
Silly? Maybe. But I think everyone who's worked on enterprise OO application has this feeling that something between these two just doesn't click. Right now, for a java developer at least, the least painful option seems to be Hibernate. Great implementation even if the whole paradigm is flawed :)
Obviously this is the twins paradox with a twist. I know that the prevailing notion has to do with the shrinkage of space but I find the explanation in the link above much more compelling.
Velocity is always relative. There is no single "middle of the universe" so every speed is relative. If the second spacecraft is stationary relative to earth, then its clock will run at the same speed as a terrestial clock.
If you board a hypothetical spacecraft right which can travel at say, 0.9c so you'll get to jupiter in time to watch the event. If you take your stopwatch with you you'll see that only a few minutses went by since you boarded the spacecraft. However for the rest of us an hour will have passed since you left. It doesn't quite make sense to say that the crash will happen at 19:00GMT. For us it will happen then, but we will find out about it an hour later (20:00GMT) because that's when the light wil l get to us. For you, the hypothetical astronaut the event will have occured at 19:10GMT.
Relativity is fun, innit?
There is no constant in the universe but c.
What if it finds a monolith there? What then? Has anyone thought about this?
English is my second language and I read it without any problems. I think it is purely a matter of your language proficiency. Non natives can definitely read and understand this.
Doesn't look like eclipse at all! Eclipse uses SWT which wraps native system widgets. This stuff uses Swing. It's really apparent if you look at the scrollbars.
Germans claim prior art
Well, specifically exclude the cost of the media in the "indemnity contract" and Linus is liable for exactly $0. He's still assuming liability it's just that he's liable for the cost of GPL software less the media it's distributed on :)
done