No kidding! I actually RTFA for a rare change, and the "bully" in that thread actually seemed like he wanted to help improve the product.
The "criticism" included hateful words along the lines of "you might want to lower the warning threshold for propeller speed because plastic propellers often can't tolerate those forces". Again, bullying? No! That's called a bug report.
If you're reading this, creyes123, you might really want to consider laying off the caffeine. Not everyone is out to get you.
Show me a company that hasn't been able to release a key piece of software because a competitor has a patent on it.
We'll never know, will we?
Show me a software company that has folded, or even scaled back operations, because of an adverse patent infringement judgment (AND where the patent was invalid due to novelty/non-obviousness, etc.)
I'm sure RIM wasn't happy having an injunction against them.
Show me any area of software research that has been crippled by any software patent.
Video compression. Unless you're one of the big players, you're effectively not allowed to participate.
Of course! Right now software patents can only be used to attack American companies. I'm sure they'd love to level the playing field.
Ridiculously incorrect. Enforcement of a U.S. patent involves a patented item or activity existing in the U.S. The nationality of the company is completely irrelevant.
If a Chinese company opens an American office and patents a software concept, they can pursue American companies that violate it. It is basically impossible for an American company to sue a Chinese company on their own turf.
In fact, non-U.S. companies have obtained patents in greater numbers over the last 15 years - both in terms of raw numbers (50,000 in 1994; 90,000 in 2007) and as compared with U.S. companies (from 43% in 1994 to 49% in 2007.)
You're bragging about the fact that we're unilaterally increasing risk to our companies at an increasing rate?
if a company spends a million bucks developing some hot algorithm, it may not wish to do so without protection, eh?
Name one algorithm that has been patented that would not have been protected by copyrights or trade secret law, and that worked to "promote the progress of science and useful arts". Just one. Any one.
What are you talking about "enter quite deep into the systems' bowels"?
That was a direct quote from the page I linked, describing how to increase the number of database connections.
How is this any different from any other server? I run my Django instances via nginx + fastcgi without any type of auto spawning, which nginx doesn't have, how does it make it any different when I've only 4 fastcgi instances running Django?
Our test Django application ran on mod_python on top of Apache 2 with the prefork MPM. 4 threads? While we're not Google, neither are we an unread blog.
If you run out of threads and the server is to its limits, you set up another server and utilize load balancing.
We ran out of threads with a load average two machines sitting idle while the reports run.
If the same intellectual "energy" goes into creating an algorithm as it does, say, a widget, should it not be awarded *some* protection?
No. Unless your last name is "Turing" or "Knuth", you probably haven't invented anything. Even then, I guarantee that your algorithm is nowhere near as important as, say, the Lorentz transformation. Good thing he and Newton and Leibniz and Einstein didn't patent their algorithms, huh?
It owns enough of them to claim that Linux is a violation of several.
I don't own any at all, but I'm going to claim that Windows violates a few of mine. I've now shown as much proof of my statement as Microsoft has of theirs.
Microsoft can buy patents.
Timeline.
Eolas.
Avistar.
Burst.com.
Gotuit.
Alcatel-Lucent.
These are all companies that sued the crap out of Microsoft over software patents. Like the saying goes, one of those companies only has to get lucky ones, while Microsoft has to get lucky every single time. Do you think they like being a target for this legal thuggery?
IT is one of the only consistently thriving segments of the U.S. economy, and the drivers of that market - Intel, IBM, Microsoft, Apple, Google, Yahoo, Adobe, eBay - all utilize and support software patents.
You couldn't be more wrong. IT is being crippled by software patents, because you can be sued for writing the most obvious things that some jackass already registered. Those companies pretty much hate software patents. Do you think Microsoft really wants Joe Troll in Texas coming after them for 20 billion dollars because he patented spreadsheets? No! They see them as an evil that they have to put up with so that they don't get run out of business by the people gaming the system.
American companies, or at least the intelligent ones, hate software patents because they're only useful against American companies. They don't do jack against the 95% of the world's population that doesn't live here, but give that 95% one hell of a big stick to beat us down with.
It's not that simple. William Gibson writes his books on an old typewriter. He can get all condescending and miss the point and say it's just his preference but the reality is that there are several advantages to using a word processor.
Conversely, there are several disadvantages to using a word processor. I think Gibson would argue that every single feature not directly related to writing words is a distraction he doesn't want, and there's a lot to be said for being forced to plan your thoughts before committing them. I don't necessarily work that way, but it really is a style preference.
Apparently you still do, and it's because of your eyes.
That was the "easy" reason. Others:
I've never found a bookmarking system as easy as a physical bookmark, and a yellow highlighter is an easier marking tool than any other I've seen.
Books don't need electricity and don't break if you sit on them, making them better (in my opinion) on trips. I've definitely never read an ebook in the bathtub.
No cute girl in a coffee shop ever asked me what ebook I was reading.
I don't have anything against digital text, and I loved php.net's docs back when I was stuck writing in that language. Given a choice between an electronic or physical version of the exact same text, though, I'll usually pick the book.
Are you referring to reloading Products which contain code changes?
Nope. We looked at Products, but they'd require more modification to our cross-application business logic layer than we really wanted to make. Basically, we didn't want to make the code a good fit for Zope specifically at the expense of making it a worse fit for everything else that used it. If Zope had been our only user of that code, sure.
To be honest, I wouldn't allow a process like Zope to render the reports by itself, I'd pass it off to a daemon running on the server.
It sounds like to me you've a serious design flaw in your application(s).
The code works like this:
User submits a form to request a report.
A Python script validates the request.
A Z SQL Method runs a query with the given parameters.
The results go to a Page Template for rendering.
Your solution:
User submits a form to request a report.
A Python script validates the request.
The user is redirected to a temporary page.
The parameters are sent to an external daemon.
The user keeps auto-refreshing the page every few seconds to see if the report is done yet.
Zope eventually finds the report.
The results go to a Page Template for rendering.
Yes, I can see why you would think that my design - which is exactly how The Zope Book tells you to do it - is seriously flawed.:-)
But I don't want to slag on Zope! It's a good app server, and was vital in getting our application to the point it's at today. It's just that we've outgrown it, and don't want to invest a huge amount of effort in making our installation yet more customized and complicated to hope we can get a few more years out of it. We're taking this chance to step back and re-evaluate some decisions and start on a slightly different path.
I bought a copy but I ended up using a pirated digital copy anyway because it was more useful...
I prefer chocolate. Does anyone even eat vanilla ice cream any more?
I can't grep a dead tree, but neither can I read much of an ebook without getting a headache. That makes the printed version much more useful to me. It's just a preference.
Without context, those numbers are meaningless. If the pages are huge, many-joined reports with lots of logic, then that's pretty good. If they're generating semi-static pages (like writing "Hello, %!" % username) up in the corner, then that's horrible.
Actually, we have precious little static content. There's the odd cacheable JavaScript or CSS file, but that's about it. I wholeheartedly agree with the concept, though. I've worked at places where we used multiple Apache daemons on the same machine, some running mod_perl etc. and the others stripped down for nothing but static content.
Well, by the time I was done with all that, I'd basically be reimplementing a different framework. With Django or Turbogears, I can let Apache spawn off as many child processes as it needs and not worry if a few of them are running slowly.
Sometimes we make quite a few changes during the day, or more specifically, we'd like to make more changes but can't easily because of the architecture we're up against.
Here's how I explained it to my boss:
Zope is an excellent product and it was absolutely the right choice at the time we picked it. We wouldn't have the web application we're enjoying today if Zope didn't exists. However, since then new options have come along that would be a better match for our needs and the way we work, and since the two main options are written in Python (which is our company's standard platform), porting the logic from Zope to a new system should be relatively easy.
Re:Never heard of Django before, now it's everwher
on
Practical Django Projects
·
· Score: 2, Informative
pylint. It has some annoying style checks that I often disable, but is good at finding unused and undeclared variables and that sort of stuff.
That's exactly the kind of stuff that had me wringing my hands. Our site involves a lot of data entry, like allowing customers to enter complex invoice information. I've heard that Turbogears is a lot better about that stuff because it doesn't make as many assumptions on your behalf, which conversely means that you have to make them yourself.
My company is moving toward using a unified codebase for our applications. Whether you're viewing an invoice in a desktop app or on the web, it's calling the same function (written in Python, using SQLAlchemy). Every time I've looked at using code in the filesystem from Zope, it's been overly complicated and problematic. Right now we use External Methods to make specific functions available inside Zope, but the side effect of that is that we have to restart the Zope process every time we want to run new code.
Another problem is that a lot of our pages take a long time to generate - think reports that take a minute or so. Because Zope is so minimally threaded, that means that other page views are delayed until those reports are finished. We use a pool of 8 Zope instances connecting to a Zeo server, with Apache sending queries to random instances to balance the load a bit. It's still too common for a use trying to view the front page to accidentally get queued up behind another using running "Financials 2004" and cursing at a blank screen until that report is done.
Add those together and you get an environment where most development is done over Webdav and is consequently a lot harder to manage with version control, 8 giant server processes are splitting the load, and changing a line of code can require a complete restart of the whole mess.
I'm getting ready to port a fairly large web app from Zope to either Django or Turbogears (easier development, more scalable for us, etc.). From what I've heard, Django is kind of the Ruby On Rails of the Python world, and while outstanding for writing small mostly-read apps, it's not the greatest for large interactive applications. Conversely, Turbogears seems to have the reputation for a higher initial learning curve and startup cost, but better interactivity.
Any thoughts on the matter? I've used Django for some small projects and my experience kind of mirrored what I'd read: it's brilliant when you want to work with it, and a complete PITA when you're trying to do something unexpected. I haven't written anything with Turbogears yet so I can't personally compare them.
No, I'm not going to make my decision solely on the opinions of Slashdot. Consider this the start of my research, not the end.:-)
Slashdot Mirror
No kidding! I actually RTFA for a rare change, and the "bully" in that thread actually seemed like he wanted to help improve the product.
The "criticism" included hateful words along the lines of "you might want to lower the warning threshold for propeller speed because plastic propellers often can't tolerate those forces". Again, bullying? No! That's called a bug report.
If you're reading this, creyes123, you might really want to consider laying off the caffeine. Not everyone is out to get you.
Crap. Did I just bully?
Show me a company that hasn't been able to release a key piece of software because a competitor has a patent on it.
We'll never know, will we?
Show me a software company that has folded, or even scaled back operations, because of an adverse patent infringement judgment (AND where the patent was invalid due to novelty/non-obviousness, etc.)
I'm sure RIM wasn't happy having an injunction against them.
Show me any area of software research that has been crippled by any software patent.
Video compression. Unless you're one of the big players, you're effectively not allowed to participate.
Wrong again. Microsoft has actually argued for expanding software patent rights in Europe. Why would it do that if it regarded software patents as a loathsome burden?
Of course! Right now software patents can only be used to attack American companies. I'm sure they'd love to level the playing field.
Ridiculously incorrect. Enforcement of a U.S. patent involves a patented item or activity existing in the U.S. The nationality of the company is completely irrelevant.
If a Chinese company opens an American office and patents a software concept, they can pursue American companies that violate it. It is basically impossible for an American company to sue a Chinese company on their own turf.
In fact, non-U.S. companies have obtained patents in greater numbers over the last 15 years - both in terms of raw numbers (50,000 in 1994; 90,000 in 2007) and as compared with U.S. companies (from 43% in 1994 to 49% in 2007.)
You're bragging about the fact that we're unilaterally increasing risk to our companies at an increasing rate?
I feel bad for the innocents, but as for him and his wife? And the rest lived happily ever after.
Thanks for the info. I'm now off to make a Freebird ringtone that's under a minute long, even though I can't stand that song.
if a company spends a million bucks developing some hot algorithm, it may not wish to do so without protection, eh?
Name one algorithm that has been patented that would not have been protected by copyrights or trade secret law, and that worked to "promote the progress of science and useful arts". Just one. Any one.
What are you talking about "enter quite deep into the systems' bowels"?
That was a direct quote from the page I linked, describing how to increase the number of database connections.
How is this any different from any other server? I run my Django instances via nginx + fastcgi without any type of auto spawning, which nginx doesn't have, how does it make it any different when I've only 4 fastcgi instances running Django?
Our test Django application ran on mod_python on top of Apache 2 with the prefork MPM. 4 threads? While we're not Google, neither are we an unread blog.
If you run out of threads and the server is to its limits, you set up another server and utilize load balancing.
We ran out of threads with a load average two machines sitting idle while the reports run.
That's great, but it's still just math (which is unpatentable).
If the same intellectual "energy" goes into creating an algorithm as it does, say, a widget, should it not be awarded *some* protection?
No. Unless your last name is "Turing" or "Knuth", you probably haven't invented anything. Even then, I guarantee that your algorithm is nowhere near as important as, say, the Lorentz transformation. Good thing he and Newton and Leibniz and Einstein didn't patent their algorithms, huh?
Same here. It looks like a sleek airplane. What's so terrible about that?
It owns enough of them to claim that Linux is a violation of several.
I don't own any at all, but I'm going to claim that Windows violates a few of mine. I've now shown as much proof of my statement as Microsoft has of theirs.
Microsoft can buy patents.
Timeline.
Eolas.
Avistar.
Burst.com.
Gotuit.
Alcatel-Lucent.
These are all companies that sued the crap out of Microsoft over software patents. Like the saying goes, one of those companies only has to get lucky ones, while Microsoft has to get lucky every single time. Do you think they like being a target for this legal thuggery?
IT is one of the only consistently thriving segments of the U.S. economy, and the drivers of that market - Intel, IBM, Microsoft, Apple, Google, Yahoo, Adobe, eBay - all utilize and support software patents.
You couldn't be more wrong. IT is being crippled by software patents, because you can be sued for writing the most obvious things that some jackass already registered. Those companies pretty much hate software patents. Do you think Microsoft really wants Joe Troll in Texas coming after them for 20 billion dollars because he patented spreadsheets? No! They see them as an evil that they have to put up with so that they don't get run out of business by the people gaming the system.
American companies, or at least the intelligent ones, hate software patents because they're only useful against American companies. They don't do jack against the 95% of the world's population that doesn't live here, but give that 95% one hell of a big stick to beat us down with.
It's not that simple. William Gibson writes his books on an old typewriter. He can get all condescending and miss the point and say it's just his preference but the reality is that there are several advantages to using a word processor.
Conversely, there are several disadvantages to using a word processor. I think Gibson would argue that every single feature not directly related to writing words is a distraction he doesn't want, and there's a lot to be said for being forced to plan your thoughts before committing them. I don't necessarily work that way, but it really is a style preference.
Apparently you still do, and it's because of your eyes.
That was the "easy" reason. Others:
I've never found a bookmarking system as easy as a physical bookmark, and a yellow highlighter is an easier marking tool than any other I've seen.
Books don't need electricity and don't break if you sit on them, making them better (in my opinion) on trips. I've definitely never read an ebook in the bathtub.
No cute girl in a coffee shop ever asked me what ebook I was reading.
I don't have anything against digital text, and I loved php.net's docs back when I was stuck writing in that language. Given a choice between an electronic or physical version of the exact same text, though, I'll usually pick the book.
I just did (in Sound Forge)... cut it down to 1:08, its just noise...
How does Sound Forge shrink it: by throwing away chunks or by generating a DCT and then resynthesizing the sound?
On the upside, I'm pretty sure it's legal to shoot escaped convicts.
Are you referring to reloading Products which contain code changes?
Nope. We looked at Products, but they'd require more modification to our cross-application business logic layer than we really wanted to make. Basically, we didn't want to make the code a good fit for Zope specifically at the expense of making it a worse fit for everything else that used it. If Zope had been our only user of that code, sure.
To be honest, I wouldn't allow a process like Zope to render the reports by itself, I'd pass it off to a daemon running on the server.
It sounds like to me you've a serious design flaw in your application(s).
The code works like this:
Your solution:
Yes, I can see why you would think that my design - which is exactly how The Zope Book tells you to do it - is seriously flawed. :-)
Or maybe it's partially because Zope by default only supports four threads, and that to get more than 7, you have to "enter quite deep into the systems' bowels".
But I don't want to slag on Zope! It's a good app server, and was vital in getting our application to the point it's at today. It's just that we've outgrown it, and don't want to invest a huge amount of effort in making our installation yet more customized and complicated to hope we can get a few more years out of it. We're taking this chance to step back and re-evaluate some decisions and start on a slightly different path.
I bought a copy but I ended up using a pirated digital copy anyway because it was more useful...
I prefer chocolate. Does anyone even eat vanilla ice cream any more?
I can't grep a dead tree, but neither can I read much of an ebook without getting a headache. That makes the printed version much more useful to me. It's just a preference.
Without context, those numbers are meaningless. If the pages are huge, many-joined reports with lots of logic, then that's pretty good. If they're generating semi-static pages (like writing "Hello, %!" % username) up in the corner, then that's horrible.
Actually, we have precious little static content. There's the odd cacheable JavaScript or CSS file, but that's about it. I wholeheartedly agree with the concept, though. I've worked at places where we used multiple Apache daemons on the same machine, some running mod_perl etc. and the others stripped down for nothing but static content.
Well, by the time I was done with all that, I'd basically be reimplementing a different framework. With Django or Turbogears, I can let Apache spawn off as many child processes as it needs and not worry if a few of them are running slowly.
Sometimes we make quite a few changes during the day, or more specifically, we'd like to make more changes but can't easily because of the architecture we're up against.
Here's how I explained it to my boss:
Zope is an excellent product and it was absolutely the right choice at the time we picked it. We wouldn't have the web application we're enjoying today if Zope didn't exists. However, since then new options have come along that would be a better match for our needs and the way we work, and since the two main options are written in Python (which is our company's standard platform), porting the logic from Zope to a new system should be relatively easy.
pylint. It has some annoying style checks that I often disable, but is good at finding unused and undeclared variables and that sort of stuff.
That's exactly the kind of stuff that had me wringing my hands. Our site involves a lot of data entry, like allowing customers to enter complex invoice information. I've heard that Turbogears is a lot better about that stuff because it doesn't make as many assumptions on your behalf, which conversely means that you have to make them yourself.
Religious groups do that. Don't tell us what to believe, but you better not do anything we don't think is right.
Like my vegetarian neighbor who bitches when we grill out and freaks out when I threaten to spank my kids?
There are plenty of categories of "annoying bore" that don't involve religious beliefs.
My company is moving toward using a unified codebase for our applications. Whether you're viewing an invoice in a desktop app or on the web, it's calling the same function (written in Python, using SQLAlchemy). Every time I've looked at using code in the filesystem from Zope, it's been overly complicated and problematic. Right now we use External Methods to make specific functions available inside Zope, but the side effect of that is that we have to restart the Zope process every time we want to run new code.
Another problem is that a lot of our pages take a long time to generate - think reports that take a minute or so. Because Zope is so minimally threaded, that means that other page views are delayed until those reports are finished. We use a pool of 8 Zope instances connecting to a Zeo server, with Apache sending queries to random instances to balance the load a bit. It's still too common for a use trying to view the front page to accidentally get queued up behind another using running "Financials 2004" and cursing at a blank screen until that report is done.
Add those together and you get an environment where most development is done over Webdav and is consequently a lot harder to manage with version control, 8 giant server processes are splitting the load, and changing a line of code can require a complete restart of the whole mess.
Yeah, we're ready to migrate.
I'm getting ready to port a fairly large web app from Zope to either Django or Turbogears (easier development, more scalable for us, etc.). From what I've heard, Django is kind of the Ruby On Rails of the Python world, and while outstanding for writing small mostly-read apps, it's not the greatest for large interactive applications. Conversely, Turbogears seems to have the reputation for a higher initial learning curve and startup cost, but better interactivity.
Any thoughts on the matter? I've used Django for some small projects and my experience kind of mirrored what I'd read: it's brilliant when you want to work with it, and a complete PITA when you're trying to do something unexpected. I haven't written anything with Turbogears yet so I can't personally compare them.
No, I'm not going to make my decision solely on the opinions of Slashdot. Consider this the start of my research, not the end. :-)
Yeah - ZFS. It really is that nice. Check out the FreeBSD wiki for an example of how cool it can be.