Yes, I did exactly that. However, the OP made it seem that there were some significant changes in 5.2 that somehow either made the book out of date or were so cool that they deserve mention in the book. Looking at the change log did not reveal such changes which is why I asked.
Context is important my friend!
Thanks. I found those from google earlier, but when I read over those lists I don't see anythign that jumps out as somethign that would make the book different or that would warrant coverage. Which of those things are really cool new features? Did any change the way you do things?
The problem is that your posts will no longer show up on their "friends" page on lj. You'll be asking your friends to take an extra step in order to keep in touch and it likely won't happen in many cases.
You fail to see an important issue in this. It's important for users looking for a blog service to know such things, and how will they know if only current lj users are allowed to talk about it (by your logic) and even they they should just shut up and leave. Isn't it a little late to find that you hate the policies of a service once you've invested a year or more creating content that benefits them and getting to know a network of friends that you'll have to leave?
I've found joel spolsky's book helpful. It's not a comprehensive management book, but there is a lot of good advice that can be gleaned from his essays.
"I write/debug/test/and version control my stored procedures just fine, thank you very much."
Do you have automated processes that run your test suite against your db code? Your db code is in subversion (or whatever)? I would love to hear about your setup. What db do you use and how do you fit tests and version control into your processes?
"How do you know at no time in the future another application won't be trying to access the database directly?"
I don't know it absolutely, but it's a risk I'm willing to take in some cases because I'm almost certain that no other application will access it. One reason is that I do web programming and I add api's to my app. If another application wants to work with the data it can use the api. No need to access the db at all.
Your example isn't a trigger or a stored procedure. Those simple constraints should be in the db. I'm talking about more complex constraints that involve logic (i.e. programming).
"Even if your application is small, you may update that table in multiple places"
"The point from the RDBMS perspective is to keep your data coherent. Data integrity is THE MOST IMPORTANT role of a database.... . That's why stored procedures and triggers and rules are important."
I agree with you in general, but isn't it just as easy to ensure data integrity via application logic as it is via triggers and stored procedures? Assuming you are only accessing the db from a single code base, I'd argue that it's easier to write/debug/test/version control/maintain ruby/python/php/java than it is to write t-sql or whatever. I know that my assumption is a big one, and that it's not true for many, but at the same time it is applicable to many people. Myself included.
It would be fairly trivial to create a handshaking system over a simple p2p network... It'd have to be user-friendly though. Of course the hand-shaking needs to be secure
I don't know what you mean by financial software and the implications. Also, what was the cost of "re-starting and running the data again"?
Also also:), agile practices wouldn't hack around a bug. You don't have to do NASA level docs/specs to have good code. Good code doesn't mean that bugs don't go live, but it does mean that you don't hack around bugs.
One of my professors(years ago) and a few of my friends work at JPL. They do engineered software and it is ungodly expensive. Millions just to produce the docs/specs. The question we have to ask ourselves is if the cost is worth it. For NASA/JPL it clearly is. For a serious web app it isn't. Agile practices give you reasonably robust code at a fraction of the cost of "engineered" code. And you get to market sooner.
The fact that most software shops have terrible practices/methods does not mean that all shops should do "engineered" code.
p.s. - I'm only using the term "engineered" because the previous posters used it. I don't think it's a fitting choice for the way we're using it here.
I can't remember if you were the OP or not, but I agree with everything that's been said. I was just pointing out that I think there are a good number of people in my situation too:)
I have a couple of questions for you if you have the time. What did you mean by "best of breed" apps? I'm guessing that you meant apps that aren't made in house. If this is the case how do stored procs help since third part apps wouldn't be coded to use the same stored procs?
Let me expand upon this a bit. Currently I'm working on a good sized site in ruby on rails. We have what you would call other apps that we've written for the site, but all are in ruby. I'm not sure if you've used ruby on rails before, but all of our business logic/db access is done through our models. All of our serious/complex data manipulation is done in these models and our other "apps" use this same code to access the db (a single point of control). This is the benefit of good design, but that's going off on a tangent. Having the data manipulation in ruby works well for us for a few reasons
it's easier to debug ruby than funky db language
ruby is more powerful and elegant than funky db language
most importantly, all of our code management processes (version control, testing, deployment, etc) are already in place and seamless for application level ruby code.
I know this isn't the case in most places, but it works great for us. I agree with all the points you made before, but I don't think that has to be the situation for all or even most people.
Slashdot Mirror
which changes made the book dated?
Yes, I did exactly that. However, the OP made it seem that there were some significant changes in 5.2 that somehow either made the book out of date or were so cool that they deserve mention in the book. Looking at the change log did not reveal such changes which is why I asked. Context is important my friend!
Thanks. I found those from google earlier, but when I read over those lists I don't see anythign that jumps out as somethign that would make the book different or that would warrant coverage. Which of those things are really cool new features? Did any change the way you do things?
I haven't used php in years. Can you link to a page that highlights the significant changes in 5.2?
"but the lower level is important."
;)
This is the under statement of the year
yeah, and those academic research institutions, which don't exist, don't get any money from public tax funds :/
it's telling me that feature is only available to paid accounts!
must be a newer feature, they didn't have it back when I used lj. Cool feature
The problem is that your posts will no longer show up on their "friends" page on lj. You'll be asking your friends to take an extra step in order to keep in touch and it likely won't happen in many cases.
Isn't the woman morally superior to the rapist in all cases? ;)
You fail to see an important issue in this. It's important for users looking for a blog service to know such things, and how will they know if only current lj users are allowed to talk about it (by your logic) and even they they should just shut up and leave. Isn't it a little late to find that you hate the policies of a service once you've invested a year or more creating content that benefits them and getting to know a network of friends that you'll have to leave?
if you are looking for an alternative, try soulcast.com
We've had a persistent user claiming that any link to porn is viewable by children, and therefore illegal, but we haven't given in.
I've found joel spolsky's book helpful. It's not a comprehensive management book, but there is a lot of good advice that can be gleaned from his essays.
they could also get your mac address if you install something of theirs.
"I write/debug/test/and version control my stored procedures just fine, thank you very much."
Do you have automated processes that run your test suite against your db code? Your db code is in subversion (or whatever)? I would love to hear about your setup. What db do you use and how do you fit tests and version control into your processes?
"How do you know at no time in the future another application won't be trying to access the database directly?"
I don't know it absolutely, but it's a risk I'm willing to take in some cases because I'm almost certain that no other application will access it. One reason is that I do web programming and I add api's to my app. If another application wants to work with the data it can use the api. No need to access the db at all.
Your example isn't a trigger or a stored procedure. Those simple constraints should be in the db. I'm talking about more complex constraints that involve logic (i.e. programming).
"Even if your application is small, you may update that table in multiple places"
You shouldn't, but most code is terrible.
"The point from the RDBMS perspective is to keep your data coherent. Data integrity is THE MOST IMPORTANT role of a database. ... . That's why stored procedures and triggers and rules are important."
I agree with you in general, but isn't it just as easy to ensure data integrity via application logic as it is via triggers and stored procedures? Assuming you are only accessing the db from a single code base, I'd argue that it's easier to write/debug/test/version control/maintain ruby/python/php/java than it is to write t-sql or whatever. I know that my assumption is a big one, and that it's not true for many, but at the same time it is applicable to many people. Myself included.
sounds like you worked for idiots. I don't think there is any solution to that problem :(
I don't know what you mean by financial software and the implications. Also, what was the cost of "re-starting and running the data again"?
:), agile practices wouldn't hack around a bug. You don't have to do NASA level docs/specs to have good code. Good code doesn't mean that bugs don't go live, but it does mean that you don't hack around bugs.
Also also
I wish I had mod points to give you.
One of my professors(years ago) and a few of my friends work at JPL. They do engineered software and it is ungodly expensive. Millions just to produce the docs/specs. The question we have to ask ourselves is if the cost is worth it. For NASA/JPL it clearly is. For a serious web app it isn't. Agile practices give you reasonably robust code at a fraction of the cost of "engineered" code. And you get to market sooner.
The fact that most software shops have terrible practices/methods does not mean that all shops should do "engineered" code.
p.s. - I'm only using the term "engineered" because the previous posters used it. I don't think it's a fitting choice for the way we're using it here.
I can't remember if you were the OP or not, but I agree with everything that's been said. I was just pointing out that I think there are a good number of people in my situation too :)
I have a couple of questions for you if you have the time. What did you mean by "best of breed" apps? I'm guessing that you meant apps that aren't made in house. If this is the case how do stored procs help since third part apps wouldn't be coded to use the same stored procs?
- it's easier to debug ruby than funky db language
- ruby is more powerful and elegant than funky db language
- most importantly, all of our code management processes (version control, testing, deployment, etc) are already in place and seamless for application level ruby code.
I know this isn't the case in most places, but it works great for us. I agree with all the points you made before, but I don't think that has to be the situation for all or even most people.but they would use the same code base so his point wouldn't make sense in that context.
it's not what i've experienced in numerous places. If it works for you that's good.