Engineering driven companies are nothing new, they're just normally not sustainable.
Semiconductor and Passives components manufacturing are normally: a. small and founded by a geek with a good idea, who either...
1. sells out early OR
2. tries to make a go of it, spends too much time on pet projects and runs the company down. b. large companies driven by suits who:
1. understand non-R&D business, ie. Sales and Operations, and remain competitive AND
2. acquire small companies run into the ground by geeks.
Why does Google do so well run by geeks? Dunno. It's astonishing they stay so focused. Guessing, maybe it's fear -- seems like they want to win so badly.
But right now every 'free' thing they do, from maps to mail, pumps the very serious ad business with eyeballs and press.
How does a project like Wine protect itself from Microsoft building compatibility insurances into its OS and App code?
In other words, MS is legally obliged to provide an OS available to third-party developers; are they also obliged to keep their Apps to be running/runnable on other systems?
Most importantly perhaps, if/as MS shifts to an Internet based deployment mechanism, are they obliged to sell-to or patch apps on Linux-based platforms?
If the answer to much of the above is no/sort-of, is an MS-Office 2K era bundle of software maybe sufficient for a few years as MS will maintain backward compatibility for a good while?
1. MVC is, definitionally, a pattern of good coding style/technique. That doesn't mean that great programmers should intuit MVC, though they might, but now at least we 'know it when we see it.' It's got a proven track-record and kids should get a dose of it in school.
2. Traditional CGI programming, little scripts here and there making web-pages, is REALLY REALLY exhausting to make MVC. It is definitely possible, but Cocoon and Struts make it MUCH easier.
3. Finally, one sentiment that keeps coming up is: ok, so I trade doing it 'well' the old way and working my butt-off OR I work my butt-off learning the frawework to do it the new way. I think this is mistaken. My experience is that when good programmers encounter good frameworks, they can intuit their way around fairly quickly.
Personally, Cocoon and Struts were like a cold drink of water and made me feel less alone in the desert.
ASP and JSP, so called embedded languages, allowed developers to install dynamic elements in an otherwise static page. A step forward in the division of labor and code re-use; developer A submits the 'date & time' tag or fragment to the HTML designer and, voila, date and time is stamped into the page or some database output or whatever.
Problem: because the page would then dump to the browser, the JSP or ASP tags were also responsible for their 'chunk' of presentation. We've learned that this 'mixing' of controller and view or data and presentation is inflexible, but sometimes expedient and easy to explain.
Answers: Cocoon and Struts are strong in 'separation of concerns' or the breaking apart of the data-model, the presentation or view of data, and the controller that binds the two.
Cocoon begins by generating content via 'generators' and xsp tags which merely create xml data. This xml is later styled into something pretty. If you don't like the presentation, you can always adjust the style. If the data source changes, just adjust the generator or revise the xsp.
Cocoon is strongest in content intensive endeavors, like catalogs and magazines, blogs and so forth.
If the need is to build something implicity dynamic, a real web-based application with a high degree of interactivity and non-determined and perhaps customized presenations, struts may be your answer. Think of porting one of your favorite apps, maybe an enterprise e-mail/scheduling system or shop-floor planning application, to the web. Struts is very strong here and 'plays' very well with other EJB based 'models' and 'controllers' in the enterprise.
HTH!
Re:Next Up in the Obvious Category...
on
Design Patterns
·
· Score: 1
"The decision [to bless most provisions of the Microsoft settlement] eliminates the establishment of a technical committee to assess Microsoft's compliance with the agreement. In its place, a corporate compliance committee -- consisting of Microsoft board members -- will make sure Microsoft lives up to the deal, the judge said."
Can we get a consensus or perhaps a poll that shows:
1. A minority of slashdotters are case modding and/or overclocking.
2. They/we would all be happier if they could exchange their thoughts in the privacy of their own little 'mods' section. Or at least fast-track them directly into hardware.
These stories are largely redundant and lead inevitably to the same bunch of threads. Furthermore, eaking a 20% to %30 speed improvement from your P4, only to be outpaced by next month's offering from Intel -- to incur all that wasted-time, money, and risk, makes about as much sense as pinning neon tubes to your box.
I'm going back under my bridge now.
Start a standards group and sign me up -- seriously. This is one of the more irritating lingering problems of the internet age, and yet it's utterly conquerable.
Say I contract with 'Personal-Data-Inc' somewhere on the 'net (one of several providers). For x$/Meg, I get to store all kinds of encrypted nonsense about myself. But probably most importantly, I store some amount of 'profile-data' -- calendar/scheduling info, contact info, messaging/mail.
Now 'PD-Inc' implements a set of XML standards and standard key-sharing schemes to allow myself and certain others access to this data. I set permissions so that members of my 'family group' have access to a diffent part of my calendar than folks in my 'job group.' And perhaps there's purely public info in there as well.
Because it's standards based, many vendors can write clients, like a Eudora or an MS-Outlook, to access this stuff. Because it's based on a permissions matrix, read/write/update occurs in controlled manner.
From the perspective of someone implementing PIPs for RosettaNet (insanely large taxonomy, lots of methods), this is relatively uncomplicated.
Slashdot Mirror
Engineering driven companies are nothing new, they're just normally not sustainable.
Semiconductor and Passives components manufacturing are normally:
a. small and founded by a geek with a good idea, who either...
1. sells out early OR
2. tries to make a go of it, spends too much time on pet projects and runs the company down.
b. large companies driven by suits who:
1. understand non-R&D business, ie. Sales and Operations, and remain competitive AND
2. acquire small companies run into the ground by geeks.
Why does Google do so well run by geeks? Dunno. It's astonishing they stay so focused. Guessing, maybe it's fear -- seems like they want to win so badly.
But right now every 'free' thing they do, from maps to mail, pumps the very serious ad business with eyeballs and press.
How does a project like Wine protect itself from Microsoft building compatibility insurances into its OS and App code? In other words, MS is legally obliged to provide an OS available to third-party developers; are they also obliged to keep their Apps to be running /runnable on other systems?
Most importantly perhaps, if/as MS shifts to an Internet based deployment mechanism, are they obliged to sell-to or patch apps on Linux-based platforms?
If the answer to much of the above is no/sort-of, is an MS-Office 2K era bundle of software maybe sufficient for a few years as MS will maintain backward compatibility for a good while?
1. MVC is, definitionally, a pattern of good coding style/technique. That doesn't mean that great programmers should intuit MVC, though they might, but now at least we 'know it when we see it.' It's got a proven track-record and kids should get a dose of it in school.
2. Traditional CGI programming, little scripts here and there making web-pages, is REALLY REALLY exhausting to make MVC. It is definitely possible, but Cocoon and Struts make it MUCH easier.
3. Finally, one sentiment that keeps coming up is: ok, so I trade doing it 'well' the old way and working my butt-off OR I work my butt-off learning the frawework to do it the new way. I think this is mistaken. My experience is that when good programmers encounter good frameworks, they can intuit their way around fairly quickly.
Personally, Cocoon and Struts were like a cold drink of water and made me feel less alone in the desert.
I think your post contains the answer.
ASP and JSP, so called embedded languages, allowed developers to install dynamic elements in an otherwise static page. A step forward in the division of labor and code re-use; developer A submits the 'date & time' tag or fragment to the HTML designer and, voila, date and time is stamped into the page or some database output or whatever.
Problem: because the page would then dump to the browser, the JSP or ASP tags were also responsible for their 'chunk' of presentation. We've learned that this 'mixing' of controller and view or data and presentation is inflexible, but sometimes expedient and easy to explain.
Answers: Cocoon and Struts are strong in 'separation of concerns' or the breaking apart of the data-model, the presentation or view of data, and the controller that binds the two.
Cocoon begins by generating content via 'generators' and xsp tags which merely create xml data. This xml is later styled into something pretty. If you don't like the presentation, you can always adjust the style. If the data source changes, just adjust the generator or revise the xsp.
Cocoon is strongest in content intensive endeavors, like catalogs and magazines, blogs and so forth.
If the need is to build something implicity dynamic, a real web-based application with a high degree of interactivity and non-determined and perhaps customized presenations, struts may be your answer. Think of porting one of your favorite apps, maybe an enterprise e-mail/scheduling system or shop-floor planning application, to the web. Struts is very strong here and 'plays' very well with other EJB based 'models' and 'controllers' in the enterprise.
HTH!
Yeah, can I get a shout-out for my boy Knuth!
Yahoo!
"The decision [to bless most provisions of the Microsoft settlement] eliminates the establishment of a technical committee to assess Microsoft's compliance with the agreement. In its place, a corporate compliance committee -- consisting of Microsoft board members -- will make sure Microsoft lives up to the deal, the judge said."
Can we get a consensus or perhaps a poll that shows: 1. A minority of slashdotters are case modding and/or overclocking. 2. They/we would all be happier if they could exchange their thoughts in the privacy of their own little 'mods' section. Or at least fast-track them directly into hardware. These stories are largely redundant and lead inevitably to the same bunch of threads. Furthermore, eaking a 20% to %30 speed improvement from your P4, only to be outpaced by next month's offering from Intel -- to incur all that wasted-time, money, and risk, makes about as much sense as pinning neon tubes to your box. I'm going back under my bridge now.
Amen!
Start a standards group and sign me up -- seriously. This is one of the more irritating lingering problems of the internet age, and yet it's utterly conquerable.
Say I contract with 'Personal-Data-Inc' somewhere on the 'net (one of several providers). For x$/Meg, I get to store all kinds of encrypted nonsense about myself. But probably most importantly, I store some amount of 'profile-data' -- calendar/scheduling info, contact info, messaging/mail.
Now 'PD-Inc' implements a set of XML standards and standard key-sharing schemes to allow myself and certain others access to this data. I set permissions so that members of my 'family group' have access to a diffent part of my calendar than folks in my 'job group.' And perhaps there's purely public info in there as well.
Because it's standards based, many vendors can write clients, like a Eudora or an MS-Outlook, to access this stuff. Because it's based on a permissions matrix, read/write/update occurs in controlled manner.
From the perspective of someone implementing PIPs for RosettaNet (insanely large taxonomy, lots of methods), this is relatively uncomplicated.