That's pretty much the essence of Oracle, really- it's very flexible and powerful, but kind of a pain in the ass to use.
This is the best summary of Oracle ever. Very true.
I've been working with Oracle on and off since v.7.3 (ca. 1996 or so). Which is sort of a worst-case - if you use it quite a bit, you start to feel comfortable, then leave it alone for a while and forget all the dumb little workarounds and tricks.
For whatever it is worth, my advice is:
Start keeping a directory of files with snippets of plsql/sql/series of steps of how you did something. If you have OCD like me, you can even make these executable scripts and everything. If you're a child of the modern world, you might instead use a wiki or something. The important thing is to keep a log of some sort - you will want to refer back to it.
Remember to google. Whenever you run in to a problem, I promise you someone else has been there before, and talked about it online. Get used to searching around.
Become comfortable with the error codes. They suck, but in their own demented way, do actually help. It takes time to learn what they're actually telling you, which is usually different than what they say
Whether or not you're concerned with optimization (and you will be, at some point), get comfortable with explain and tkprof. Wrapping your head around how the optimizer works gives a fair amount of insight that is generally useful.
Don't be afraid of plsql. It sometimes feels as if you're building a house in the dark or something, but there's a lot of value in it. I know several folks who draw a hard line here - "well, I can use it like a DB, but programming in it is not what I do". They miss out on a lot of the value of Oracle.
Make sure you're comfortable with sqlplus. The Quest tools are great, and vastly improve productivity, but the time will come when you need to muck around with the v$ and dba_whatever tables, or have to manually reset a sequence, or something, and making sure you can handle sqlplus (and selecting out the twisted joins required to get anything useful out of said tables) is invaluble. I am not making this up: last time I had a full time job, I got a promotion out of the fact that I was the only one in engineering who was able to use it to diagnose a weird logic problem. (Well, there were other factors, but a high-pressure situation when you can ask and get answers from the DB and nobody else can looks impressive. I have not yet tried this technique with the ladies.)
And all the general database tips: if you aren't already good at design, learn, learn, learn. Don't ignore the theory: if you don't know the difference between third-normal and Boyce-Codd, go learn it. Don't just read: make test DBs in each form, and build test cases in each one. Make sure you understand at least the basics of set theory. I'm not kidding - folks will tell you it doesn't matter, but the difference between a competent DB developer and a great one is frequently a deep understanding of theory. Being in a line of work that exposes me to designs done by a lot of other people, I can tell a surprising amount about their knowledge and work habits by looking at how they build DBs.
Anyway. That ended up being kind of a random brain dump. Hope something was useful.
Someone is going to call me a tinfoil hat wearing nutcase for this, but anyone can simply google around for evidence of the U.S. and France being engaged in a low-level commercial information war, Israel being fairly invasive with intelligence efforts in the US, and, well, just go look at some of the stuff that was going on with Inslaw.
Commercial involvment (willing or not) with spying for nation states is alive and well. I know nothing on the topic, but would be very surprised if Microsoft hasn't at least talked to someone from a TLA.
Whereas clearly spelling, grammar, and basic maths are completely different, and we should not be making any effort to help people take their mind away from niggling details and let them concentrate on the content of their writing or the implications of their calculations.
Well, they are completely different. They are thinking and communication skills. Spelling may be slightly mechanical, but knowing proper spelling can also save you from embarrassing conversational gaffes. (Can also help with other languages, depending on your native tongue.) Try puzzling out even mildly complicated calculus without a firm grasp of basic math. You don't have any in-build sanity checking, and you don't develop the room for intuitive leaps. Communication is more so, only without the advantage of being able to be explicitly incorrect in the same way one can be with math.
If your theory that we're moving into an age where mechanical abilities are automated (and I think you're right), thinking and communicating are going to be highly valued at the expense of automation, and how one communicates even more of a social identifier than it is now.
Not really. It's in the HTTP RFC. GET requests are supposed to be idempotent. POST requests are not.
We're probably disagreeing with what it means to discover a simple rule.
Yes, RFC1945 was approved, what ten years ago? And how often to simple webapps written today actually follow the basic observations contained therein?
I would suggest that the GET/POST dichotomy for handling data is a useful (lossy, I admit) way to beat crappy web developers over the head with a simple idea that makes the web a better place. It should have been learned a long time ago, but it hasn't been. I'm way cool on any effort that makes the script kiddies do something somewhat in line with something approaching best practice. Nobody loses.
What a great reply! It's clear and it opens the discussion to everyone, probably much like your website designs....
Thank you. Like I said, I try to communicate with the person I'm talking to.
There are no end of poorly constructed, poorly spelled, poorly conceived websites, written in languages and using tools that almost encourage this junk.
Yep. That's why I'm in business - we're one part garbage collectors, two parts architects, one part graphic designers. We're not big enough that people call us first, but we clean up after other consultants fuck everything up. And, it's a growing business. I'm of two minds - clearly, I like making money, so it is great for me. But I think we could all be doing much more interesting things if people would just stop cutting corners. Some of what I do is fun - solving new problems, or trying to shoehorn an established business process into an online world, or (in some cases) walking managers though changing business processes. But a lot of it is just what I call forensic plumbing. "Why's the water squirting out over there?"
As a matter of fact, I'm writing in one now - slashdot's text entry screen is too narrow.
I'm not about to defend slashdot's design, either from a code (shudder) or a usability standpoint. But, you can change that - if you're logged in, click here, or just navigate through the preferences section. As I said, this is clearly shitty design, but at least Taco and company threw up their hands and made preference options, which is more than I can say for 80% of the sites out there.
It's nice that you speak your own discipline-specific version of acronym so well! Felicitations!
Well, sorry, but it is a domain-specific conversation. For the record, I speak set theory with database geeks, mathematese with math geeks, and german with Germans, too.
From what little I could decypher, much of this seems like a control issue. You guys want to control precisely what my browser does and so do I. Might I suggest that there are times that it is completely correct to render the precise page from the user's cache no matter the insanely complicated goings on at the programmer's end? If it isn't possible to signal those instances when that might be done, I suggest your software is broken.
That's exactly what I was getting at. To remove the technicalities, the problem boils down to this. If all web applications were properly coded, then browsers could make the right choices and properly render from cache when appropriate, and make a network request when it isn't. However, we don't live in a perfect world, and there are lots of crappy apps out there. Therefor, browsers need to be tolerant of edge cases (they can't detect crappy web app coders) and make sometimes-spurious network requests, or people would be angry at browser makers, instead of the crappy app developers, when things went horribly wrong and someone purchased 18 flower deliveries instead of one without realizing it. This is the old "be liberal in what you accept, and conservative in what you send" maxim. (RIP, JP.)
For the record, I want the user to be in complete control of the experience on sites I build (modulo obvious security, privacy and asshat concerns). That's the whole point. I want them to use it however they see fit, because (and I realize this sounds obvious, but it isn't at all to a lot of developers) that means people use your service more. That's the point of building it, isn't it?
In order to do that, the developer is obligated to do things correctly. For a case study in incorrect design, seek out your closest custom vertical Java webapp; I'll bet even money whoever built it forgot that Tomcat is the controller, and uses Javascript for the links when it just makes more work to do so. I'm currently in a protracted argument with a client about why this is such a bad design "pattern". (Sorry, fell back into jargon there.)
Consultant: No, what I'm asking is, do you want us to build the method that works, which you hired us to discover and spec out for you, or the broken one, for which you're now asking?
Client: The broken one!
Consultant: You're sure.
Client: Are you billing me for this conversation?
It's not just inconvenient. It's wrong in principle; 'back' should be 'back to precisely what I received previously', not 'attempt to re-get whatever now appears at the previous URL.' If I want the page refreshed, I will use the provided 'refresh' button, mkay? Thanks.
So, the big deal here is maintaining consensual state. I'm sure you know the basics here. Best practice is to POST when changing state on the server, and GET when reading. But, not everone does that. And it also took a long time to come up with that simple rule. The upshot is that when using browser based C/S apps, there is no good way to tell if the last action changed the state of whatever it is you're looking at. (For a simple example, think of confirming a bank transfer, and hitting back from the "it worked" page.) And even the POST means change rule doesn't always work or apply. Good app design has to play a role, but a browser has no idea if what is going on with the server.
There are other reasons why back can't always be exactly "what you got a page ago", but the above is the main killer (from the perspective of what I do, at least). Developers can make this better by playing tricks with the last-modified header and whatnot, but you're either going to sometimes get broken info or at least do a HEAD when going back, take your pick.
It is notable that the whole AJAX obsession usually completely kills the back button, and many web developers are very hot on the idea. If global state, session, and sometimes transaction can be bound that much more tightly, it does make life easier for a coder, at the expense of some great client side functionality. (Again, depending on how you think of it.)
Doesn't mean I'm not using XMLRPC - I don't mind bragging that we were doing some of this a few years ago. Having a community to trade ideas with kicks ass, and I've learned a lot from other's experimentation. But we shouldn't lose track of basics, like "the browser is not just a window frame; inbuilt functionality is important and if you make your own back buttons, you're missing the point."
I haven't sucked it down yet (can't risk breaking my browser until the weekend), but the release notes say SVG it is there. Woohoo! I'm all over this, too.
In the design of any of our service architectures, we have several requirements that must be met before we would consider deployment. For email, the first of these is message integrity. It is absolutely essential that messages, once they are accepted by our system, be delivered to their proper destination intact. Second, the system must be robust. That is, in as much as is possible, the system should survive component outages gracefully. Additionally, the entire system design should minimize the number of single points of failure. Third, the system must be scalable. When EarthLink began deployment of the current architecture, in January of 1996, we had about 25,000 subscribers. In September of 1997, EarthLink provided email service for over 350,000 subscribers with a 99.9+% service uptime record. In fact, we expect the current system to scale to well over 1,000,000 users without significant alteration of the architecture as presented here. Moreover, one should be able to accomplish the scaling of any service with a minimum of outage time, preferably with none. In all cases the performance of the service must be at least adequate, and the service must be maintainable. Problems must be easily recognizable, and it should be obvious, whenever possible, what is the cause of the outage. Further, its solution should be easy to implement and, in the meantime, the impact of the outage should be small and locally confined. Finally, we would like the service architecture to be cost-effective, not just in terms of equipment acquisition, but, more critically, in terms of maintenance.
I got the impression from the questions posed in that call that Google really don't have a clue how to hire. They seem to hire based on same technique as Japanese entrance exams.. i.e. pure knowledge bits are more important than conceptual understanding or problem solving...
Then you missed the point of the interview completely. They're looking for smart people with excellent problem solving skills, creativity and curiousity. Take a really smart person and you can teach them QA if you have to. Take a mediocre person with lots of QA and then try to teach them anything outside their narrow field.
Last person I hired as a programmer had little actual professional programming experience. He'd been working as a studio musician. One of the best hires I ever made. (Granted, it was at first for mostly front end work, but he's expanded into heavier stuff over time.) Being smart, a fast learner, detail oriented, curious, and having a diverse background is *exactly* what I look for.
Someone flagged this as funny, but I agree with the notion, and question anyone who disagrees. Sure, that's how it used to work. We used to be able to mock them after the fact. No more. Government should function in the full light of day now. Watch them. Don't tell me it is like making sausage - that's an excuse. Hold people accountable, and manage your own government. Bite me, if you don't manage your executives, who will? Take some responsibility, for dog's sake.
Kiitti! (Paljon kiitoksia? I'm unclear on formality rules. And case. Sorry.)
Many of us speak pretty good English too, and especially the younger people are probably generally more adept with it than Swedish, since both are taught at schools, but Internet and TV make mastering English actually useful, and that's what counts for wanting to learn something...
I was mainly referring to immigration law, which appears to welcome schmucks like me who have earning potential, so long as they make a good faith effort to blend in. Swedish is only an angle for me because I can already mostly passively understand it, if not speak it. From the perspective of someone who natively speaks English and is fluent in German and Spanish and speaks some French and a tiny bit of Italian, Finnish is a pretty perverse language... That's sort of why I'm enjoying trying to learn it. The only thing less intuitive I've tried was Mandarin, which, well, I had no reason to keep trying at.
The main barrier is not primarily language. Moving a family and a business is a big challenge. So long as I stay awake all night and eat the cost of phone calls, I can probably keep existing clients, but it is a huge risk to relocate to a place where I can't speak the native language and have almost no contacts. I want to, but it is hard. I'm not well suited to the work-for-a-company game; I doubt anyone would want to hire me (Hell, I wouldn't hire me - if I'm not in charge, I'm a pain in the ass.). So options are limited.
Know any local firms who need software engineering consultants? My partner does speak fluent French, so that's a communication channel option, too. (And Old and Middle English, Saxon and Latin, but I suspect those are of only nominal value.)
If you think there are better places to live, you're always free to move there. If you're planning on moving to a socialist country, though, I'd advise leaving yourself a decade or so, governments of that type have even worse red tape than the US
Oddly enough, that's not true. Check out Finland as a destination: they're quite accomodating. Yes, I'm considering it. Sure, the language is a bitch, but you can learn Swedish, which is much easier (and my route, as I already speak German). The logistics of moving a family and a business are the hard parts, not some baggage from the evil commies. And have you looked at the tightening of US immigration lately? ("but we're a war. That's different. 9/11 changed everything.")
Also, your 'quality of life' argument is a crock, as are all 'quality of life' arguments, because the speaker always simply defines the term to mean what he wants.
Tell that to someone sitting in the Superdome, while soldiers stop the Red Cross from bringing in supplies, and George apes for the cameras in front of helicopters sitting idle for the photo-op.
The best summary of this situation was voiced a while back, and I can't remember who said it. The notion was that lot of people in the area hoped that Haiti would start to look more like New Orleans, but instead, New Orleans now looks like Haiti.
This is the biggest federal train-wreck, I think, since the Civil War. (I could be wrong, and overwrought with what I'm seeing.) But, hey, Trent Lott's gonna get a nice porch, so it is all OK, right?
Most machines I use use the sendmail command, which, AFAIK, connects directly to the MX for the receiving domains. I like this behavior, because (1) it doesn't put unnecessary load on any outgoing SMTP server, (2) doesn't have a single point of failure, and (3) doesn't allow the administrator of the outgoing server to inspect/filter/modify/reject the mail I send.
(0) Depends on how your boxes are configured. Once you have a smarthost, configing sendmail/postfix/whatever to use it is trivial.
(1) The incremental load of an email message is trivial. If you're smarhost is overloaded... beef it up - this is like any other capacity issue.
(2) Mail is robust. (spam is causing people to break some of the things that make is robust, but it is still pretty good.) Having a failover/backup MX host/backup smarthost is easy enough that organizations who do enough volume for it to matter should have a plan for that. Hell, my company does less than 1000 outgoing messages a day, and we do.
(3) Possibly legitimate, probably futile. If someone wants to read your mail and you're on their network, use PGP, or you're doomed. Transparent proxies are only the easiest way to grab it.
Personally, I'm a big fan of companies/orgs running their own SMTP servers, and using them. Every-box-sends, especially today, is a real issue, and the win of not configuring sendmail to use a smarthost is balanced by the fact that if you want to get through spam filters, you need to configure DNS for every machine, and monitor them to make sure they're not doing something bad. Choose your poison.
I don't like taking this to the extreme that some seem to favor, requiring everyone to use the ISP's smarthost. That does become a real chokepoint where potential monitoring takes on a different tone, where I can't control the TLS, incoming authentication or spam filtering, and where someone else's actions can stop my mail delivery. But for companies, one (or sometimes more) outbound SMTP server(s) per site makes a lot of sense.
Again, a personal anecdote - If we didn't do it this way, it probably would have taken me much longer to realize the Windows installation I built under VMware a while back had been zombified before I could patch it. As it happened, while it was patching, I checked my mail and my firewall was screaming about it trying to send mail (and connect to IRC, but that's not the question at hand.)
I realize not everyone has the skill or takes the time to run a tight network, but mail isn't hard for the vast majority of sites to get right - there's almost nothing to it these days.
It isn't that hard, really. Or maybe I spent too much time reading my prof's attacks on me... Really, it isn't that hard to read.
Now, understaning it, that's different. I don't have a don't have a degree that would help. (I did calc in a German school, and won awards for various Stupid Math Tricks while there. But I'm over 30 now, and I don't pretend I'm going to do anything interesting.)
I'm going to be reading this for a while. Some of it is hard to translate, some is hard to transliterate, and some of just hard. Fucking cool stuff.
Sorry to follow up on my own post, but I meant to add that a similar betting-pool idea for knowledge aggregation was put forth by John Brunner's brilliant (IMO) book Shockwave Rider, in 1975. (If you like SF, read it, if you haven't. There's a lot more than just the betting thing going on that still echos in modern SF fiction, plus, it is a great story, even if the writing sort of sucks. But we're used to that is SF, yes?)
Sure. This is a longer-term gamble (and a PR stunt, even if a good one, and with a purpose). AFAIK, one can't buy, say, 20 year futures on the weather.
Robin Hansen has been trying to set up markets in this sort of thing for a while, but with little success. It seems that, for the most part, people get more than a little conservative*, and not only don't want to bet, but also don't want to see the odds.
*I'm using that in the general sense, not the current flame-fest sense.
Even if that happens, warming in the short term should still occur; and maybe even in the long term. I can't say I'm an expert in global warming, but I would imagine that even if everyone stopped emitting greenhouse gases today, what's already out there is already out there.
that's a very good point. i think that's a crucial reason why freebsd has already lost this 'market'
I think you're responding to this:
otoh, openbsd developers develop because they want to. they want quality software that's *free*. freebsd developers seem to have gone the "we want something that works" route, and that's too bad
(If you're not responding to that, please ignore this post.)
There's been a lot of heat of this, and not much light. One can argue about whether goal X is better served by building something, or using a tool with a different license, certainly. And I'd agree that, all other things being equal, free is the way to go. I might even say that long-term, free will beat expedient (I'd like to believe that's always the case, but it isn't.).
But all other things are not equal, and I tend to trust the fBSD folks. They've made more than one good decision in the past that has pissed people off, and the OS still rocks. (I've had my laptop running it for a while, after having moved for the most part to Debian for a few years for business reasons. I'm planning on moving my main desktop back to fBSD when I have some time - I hadn't realized how much I missed the feel of it until I started playing with it again.) I don't think it is a bad thing to be pulled by commercial interests, so long as you keep your long term goals independent of your short-term goals; hell, how is this different than any (non-independently wealthy) poster on this thread?
Friend, you don't have a perl problem. You have someone who needs to be removed from the project, or at the very least, whacked on the head with a data structures book every time they try a new interpolation trick out. And steal their perlmonks password and lock the account.
Even better, don't actually rewrite the app, just refactor it.
I have to agree. If you've got 40K members now, you have a lot to lose, and trust me, unless you hire an experienced team to replace your code, you probably will lose a lot of them when you transition to a new code base. There is a lot of sunk knowledge in that code, and you've probably forgotten why some of the spagetti was actually mostly a good idea at the time. So take it apart slowly.
Bring up a stage under mod_perl, and see what breaks. Most folks having trouble with Perl OO have trouble because it is permissive - it is up to you to find the style you like (and not muck around in other module's sandboxes). So pick one of them, and go with it. Other than that, I have little to add to what the parent poster said. Oh, and don't copy-paste clever/stupid map() tricks lifted from others unless you actually know what they do.
I still say there's no better language for text processing, of which web presentation is one application subset.
Slashdot Mirror
Hm, I'm not sure that I want to purchase product from someone who informs me that:
"Raping The Phone Can Cause A Increase In Power Out Put"
(Scroll down to the red text.)
Just buy a license to show MTV or something on a screen and stick it anywhere you don't want people taking pictures.
This is the best summary of Oracle ever. Very true.
I've been working with Oracle on and off since v.7.3 (ca. 1996 or so). Which is sort of a worst-case - if you use it quite a bit, you start to feel comfortable, then leave it alone for a while and forget all the dumb little workarounds and tricks.
For whatever it is worth, my advice is:
- Start keeping a directory of files with snippets of plsql/sql/series of steps of how you did something. If you have OCD like me, you can even make these executable scripts and everything. If you're a child of the modern world, you might instead use a wiki or something. The important thing is to keep a log of some sort - you will want to refer back to it.
- Remember to google. Whenever you run in to a problem, I promise you someone else has been there before, and talked about it online. Get used to searching around.
- Become comfortable with the error codes. They suck, but in their own demented way, do actually help. It takes time to learn what they're actually telling you, which is usually different than what they say
- Whether or not you're concerned with optimization (and you will be, at some point), get comfortable with explain and tkprof. Wrapping your head around how the optimizer works gives a fair amount of insight that is generally useful.
- Don't be afraid of plsql. It sometimes feels as if you're building a house in the dark or something, but there's a lot of value in it. I know several folks who draw a hard line here - "well, I can use it like a DB, but programming in it is not what I do". They miss out on a lot of the value of Oracle.
- Make sure you're comfortable with sqlplus. The Quest tools are great, and vastly improve productivity, but the time will come when you need to muck around with the v$ and dba_whatever tables, or have to manually reset a sequence, or something, and making sure you can handle sqlplus (and selecting out the twisted joins required to get anything useful out of said tables) is invaluble. I am not making this up: last time I had a full time job, I got a promotion out of the fact that I was the only one in engineering who was able to use it to diagnose a weird logic problem. (Well, there were other factors, but a high-pressure situation when you can ask and get answers from the DB and nobody else can looks impressive. I have not yet tried this technique with the ladies.)
- And all the general database tips: if you aren't already good at design, learn, learn, learn. Don't ignore the theory: if you don't know the difference between third-normal and Boyce-Codd, go learn it. Don't just read: make test DBs in each form, and build test cases in each one. Make sure you understand at least the basics of set theory. I'm not kidding - folks will tell you it doesn't matter, but the difference between a competent DB developer and a great one is frequently a deep understanding of theory. Being in a line of work that exposes me to designs done by a lot of other people, I can tell a surprising amount about their knowledge and work habits by looking at how they build DBs.
Anyway. That ended up being kind of a random brain dump. Hope something was useful.Commercial involvment (willing or not) with spying for nation states is alive and well. I know nothing on the topic, but would be very surprised if Microsoft hasn't at least talked to someone from a TLA.
Well, they are completely different. They are thinking and communication skills. Spelling may be slightly mechanical, but knowing proper spelling can also save you from embarrassing conversational gaffes. (Can also help with other languages, depending on your native tongue.) Try puzzling out even mildly complicated calculus without a firm grasp of basic math. You don't have any in-build sanity checking, and you don't develop the room for intuitive leaps. Communication is more so, only without the advantage of being able to be explicitly incorrect in the same way one can be with math.
If your theory that we're moving into an age where mechanical abilities are automated (and I think you're right), thinking and communicating are going to be highly valued at the expense of automation, and how one communicates even more of a social identifier than it is now.
We're probably disagreeing with what it means to discover a simple rule.
Yes, RFC1945 was approved, what ten years ago? And how often to simple webapps written today actually follow the basic observations contained therein?
I would suggest that the GET/POST dichotomy for handling data is a useful (lossy, I admit) way to beat crappy web developers over the head with a simple idea that makes the web a better place. It should have been learned a long time ago, but it hasn't been. I'm way cool on any effort that makes the script kiddies do something somewhat in line with something approaching best practice. Nobody loses.
Thank you. Like I said, I try to communicate with the person I'm talking to.
There are no end of poorly constructed, poorly spelled, poorly conceived websites, written in languages and using tools that almost encourage this junk.
Yep. That's why I'm in business - we're one part garbage collectors, two parts architects, one part graphic designers. We're not big enough that people call us first, but we clean up after other consultants fuck everything up. And, it's a growing business. I'm of two minds - clearly, I like making money, so it is great for me. But I think we could all be doing much more interesting things if people would just stop cutting corners. Some of what I do is fun - solving new problems, or trying to shoehorn an established business process into an online world, or (in some cases) walking managers though changing business processes. But a lot of it is just what I call forensic plumbing. "Why's the water squirting out over there?" As a matter of fact, I'm writing in one now - slashdot's text entry screen is too narrow.
I'm not about to defend slashdot's design, either from a code (shudder) or a usability standpoint. But, you can change that - if you're logged in, click here, or just navigate through the preferences section. As I said, this is clearly shitty design, but at least Taco and company threw up their hands and made preference options, which is more than I can say for 80% of the sites out there.
Well, sorry, but it is a domain-specific conversation. For the record, I speak set theory with database geeks, mathematese with math geeks, and german with Germans, too.
From what little I could decypher, much of this seems like a control issue. You guys want to control precisely what my browser does and so do I. Might I suggest that there are times that it is completely correct to render the precise page from the user's cache no matter the insanely complicated goings on at the programmer's end? If it isn't possible to signal those instances when that might be done, I suggest your software is broken.
That's exactly what I was getting at. To remove the technicalities, the problem boils down to this. If all web applications were properly coded, then browsers could make the right choices and properly render from cache when appropriate, and make a network request when it isn't. However, we don't live in a perfect world, and there are lots of crappy apps out there. Therefor, browsers need to be tolerant of edge cases (they can't detect crappy web app coders) and make sometimes-spurious network requests, or people would be angry at browser makers, instead of the crappy app developers, when things went horribly wrong and someone purchased 18 flower deliveries instead of one without realizing it. This is the old "be liberal in what you accept, and conservative in what you send" maxim. (RIP, JP.)
For the record, I want the user to be in complete control of the experience on sites I build (modulo obvious security, privacy and asshat concerns). That's the whole point. I want them to use it however they see fit, because (and I realize this sounds obvious, but it isn't at all to a lot of developers) that means people use your service more. That's the point of building it, isn't it?
In order to do that, the developer is obligated to do things correctly. For a case study in incorrect design, seek out your closest custom vertical Java webapp; I'll bet even money whoever built it forgot that Tomcat is the controller, and uses Javascript for the links when it just makes more work to do so. I'm currently in a protracted argument with a client about why this is such a bad design "pattern". (Sorry, fell back into jargon there.)
Consultant: No, what I'm asking is, do you want us to build the method that works, which you hired us to discover and spec out for you, or the broken one, for which you're now asking?
Client: The broken one!
Consultant: You're sure.
Client: Are you billing me for this conversation?
Fair enough; I didn't get it the first pass. I wasn't there. Google might be stupid. I was, perhaps, projecting. My Fault.
So, the big deal here is maintaining consensual state. I'm sure you know the basics here. Best practice is to POST when changing state on the server, and GET when reading. But, not everone does that. And it also took a long time to come up with that simple rule. The upshot is that when using browser based C/S apps, there is no good way to tell if the last action changed the state of whatever it is you're looking at. (For a simple example, think of confirming a bank transfer, and hitting back from the "it worked" page.) And even the POST means change rule doesn't always work or apply. Good app design has to play a role, but a browser has no idea if what is going on with the server.
There are other reasons why back can't always be exactly "what you got a page ago", but the above is the main killer (from the perspective of what I do, at least). Developers can make this better by playing tricks with the last-modified header and whatnot, but you're either going to sometimes get broken info or at least do a HEAD when going back, take your pick.
It is notable that the whole AJAX obsession usually completely kills the back button, and many web developers are very hot on the idea. If global state, session, and sometimes transaction can be bound that much more tightly, it does make life easier for a coder, at the expense of some great client side functionality. (Again, depending on how you think of it.)
Doesn't mean I'm not using XMLRPC - I don't mind bragging that we were doing some of this a few years ago. Having a community to trade ideas with kicks ass, and I've learned a lot from other's experimentation. But we shouldn't lose track of basics, like "the browser is not just a window frame; inbuilt functionality is important and if you make your own back buttons, you're missing the point."
I haven't sucked it down yet (can't risk breaking my browser until the weekend), but the release notes say SVG it is there. Woohoo! I'm all over this, too.
Part of the abstract:
Then you missed the point of the interview completely. They're looking for smart people with excellent problem solving skills, creativity and curiousity. Take a really smart person and you can teach them QA if you have to. Take a mediocre person with lots of QA and then try to teach them anything outside their narrow field.
Last person I hired as a programmer had little actual professional programming experience. He'd been working as a studio musician. One of the best hires I ever made. (Granted, it was at first for mostly front end work, but he's expanded into heavier stuff over time.) Being smart, a fast learner, detail oriented, curious, and having a diverse background is *exactly* what I look for.
Someone flagged this as funny, but I agree with the notion, and question anyone who disagrees. Sure, that's how it used to work. We used to be able to mock them after the fact. No more. Government should function in the full light of day now. Watch them. Don't tell me it is like making sausage - that's an excuse. Hold people accountable, and manage your own government. Bite me, if you don't manage your executives, who will? Take some responsibility, for dog's sake.
Kiitti! (Paljon kiitoksia? I'm unclear on formality rules. And case. Sorry.)
Many of us speak pretty good English too, and especially the younger people are probably generally more adept with it than Swedish, since both are taught at schools, but Internet and TV make mastering English actually useful, and that's what counts for wanting to learn something...
I was mainly referring to immigration law, which appears to welcome schmucks like me who have earning potential, so long as they make a good faith effort to blend in. Swedish is only an angle for me because I can already mostly passively understand it, if not speak it. From the perspective of someone who natively speaks English and is fluent in German and Spanish and speaks some French and a tiny bit of Italian, Finnish is a pretty perverse language... That's sort of why I'm enjoying trying to learn it. The only thing less intuitive I've tried was Mandarin, which, well, I had no reason to keep trying at.
The main barrier is not primarily language. Moving a family and a business is a big challenge. So long as I stay awake all night and eat the cost of phone calls, I can probably keep existing clients, but it is a huge risk to relocate to a place where I can't speak the native language and have almost no contacts. I want to, but it is hard. I'm not well suited to the work-for-a-company game; I doubt anyone would want to hire me (Hell, I wouldn't hire me - if I'm not in charge, I'm a pain in the ass.). So options are limited.
Know any local firms who need software engineering consultants? My partner does speak fluent French, so that's a communication channel option, too. (And Old and Middle English, Saxon and Latin, but I suspect those are of only nominal value.)
Gah. I'm rambling now. Sorry.
Oddly enough, that's not true. Check out Finland as a destination: they're quite accomodating. Yes, I'm considering it. Sure, the language is a bitch, but you can learn Swedish, which is much easier (and my route, as I already speak German). The logistics of moving a family and a business are the hard parts, not some baggage from the evil commies. And have you looked at the tightening of US immigration lately? ("but we're a war. That's different. 9/11 changed everything.")
Also, your 'quality of life' argument is a crock, as are all 'quality of life' arguments, because the speaker always simply defines the term to mean what he wants.
Tell that to someone sitting in the Superdome, while soldiers stop the Red Cross from bringing in supplies, and George apes for the cameras in front of helicopters sitting idle for the photo-op.
The best summary of this situation was voiced a while back, and I can't remember who said it. The notion was that lot of people in the area hoped that Haiti would start to look more like New Orleans, but instead, New Orleans now looks like Haiti.
This is the biggest federal train-wreck, I think, since the Civil War. (I could be wrong, and overwrought with what I'm seeing.) But, hey, Trent Lott's gonna get a nice porch, so it is all OK, right?
(0) Depends on how your boxes are configured. Once you have a smarthost, configing sendmail/postfix/whatever to use it is trivial.
(1) The incremental load of an email message is trivial. If you're smarhost is overloaded... beef it up - this is like any other capacity issue.
(2) Mail is robust. (spam is causing people to break some of the things that make is robust, but it is still pretty good.) Having a failover/backup MX host/backup smarthost is easy enough that organizations who do enough volume for it to matter should have a plan for that. Hell, my company does less than 1000 outgoing messages a day, and we do.
(3) Possibly legitimate, probably futile. If someone wants to read your mail and you're on their network, use PGP, or you're doomed. Transparent proxies are only the easiest way to grab it. Personally, I'm a big fan of companies/orgs running their own SMTP servers, and using them. Every-box-sends, especially today, is a real issue, and the win of not configuring sendmail to use a smarthost is balanced by the fact that if you want to get through spam filters, you need to configure DNS for every machine, and monitor them to make sure they're not doing something bad. Choose your poison.
I don't like taking this to the extreme that some seem to favor, requiring everyone to use the ISP's smarthost. That does become a real chokepoint where potential monitoring takes on a different tone, where I can't control the TLS, incoming authentication or spam filtering, and where someone else's actions can stop my mail delivery. But for companies, one (or sometimes more) outbound SMTP server(s) per site makes a lot of sense.
Again, a personal anecdote - If we didn't do it this way, it probably would have taken me much longer to realize the Windows installation I built under VMware a while back had been zombified before I could patch it. As it happened, while it was patching, I checked my mail and my firewall was screaming about it trying to send mail (and connect to IRC, but that's not the question at hand.)
I realize not everyone has the skill or takes the time to run a tight network, but mail isn't hard for the vast majority of sites to get right - there's almost nothing to it these days.
Now, understaning it, that's different. I don't have a don't have a degree that would help. (I did calc in a German school, and won awards for various Stupid Math Tricks while there. But I'm over 30 now, and I don't pretend I'm going to do anything interesting.)
I'm going to be reading this for a while. Some of it is hard to translate, some is hard to transliterate, and some of just hard. Fucking cool stuff.
Sorry to follow up on my own post, but I meant to add that a similar betting-pool idea for knowledge aggregation was put forth by John Brunner's brilliant (IMO) book Shockwave Rider, in 1975. (If you like SF, read it, if you haven't. There's a lot more than just the betting thing going on that still echos in modern SF fiction, plus, it is a great story, even if the writing sort of sucks. But we're used to that is SF, yes?)
Robin Hansen has been trying to set up markets in this sort of thing for a while, but with little success. It seems that, for the most part, people get more than a little conservative*, and not only don't want to bet, but also don't want to see the odds.
*I'm using that in the general sense, not the current flame-fest sense.
Well, that really says it all, doesn't it?
I think you're responding to this:
otoh, openbsd developers develop because they want to. they want quality software that's *free*. freebsd developers seem to have gone the "we want something that works" route, and that's too bad
(If you're not responding to that, please ignore this post.)
There's been a lot of heat of this, and not much light. One can argue about whether goal X is better served by building something, or using a tool with a different license, certainly. And I'd agree that, all other things being equal, free is the way to go. I might even say that long-term, free will beat expedient (I'd like to believe that's always the case, but it isn't.).
But all other things are not equal, and I tend to trust the fBSD folks. They've made more than one good decision in the past that has pissed people off, and the OS still rocks. (I've had my laptop running it for a while, after having moved for the most part to Debian for a few years for business reasons. I'm planning on moving my main desktop back to fBSD when I have some time - I hadn't realized how much I missed the feel of it until I started playing with it again.) I don't think it is a bad thing to be pulled by commercial interests, so long as you keep your long term goals independent of your short-term goals; hell, how is this different than any (non-independently wealthy) poster on this thread?
Friend, you don't have a perl problem. You have someone who needs to be removed from the project, or at the very least, whacked on the head with a data structures book every time they try a new interpolation trick out. And steal their perlmonks password and lock the account.
I have to agree. If you've got 40K members now, you have a lot to lose, and trust me, unless you hire an experienced team to replace your code, you probably will lose a lot of them when you transition to a new code base. There is a lot of sunk knowledge in that code, and you've probably forgotten why some of the spagetti was actually mostly a good idea at the time. So take it apart slowly.
Bring up a stage under mod_perl, and see what breaks. Most folks having trouble with Perl OO have trouble because it is permissive - it is up to you to find the style you like (and not muck around in other module's sandboxes). So pick one of them, and go with it. Other than that, I have little to add to what the parent poster said. Oh, and don't copy-paste clever/stupid map() tricks lifted from others unless you actually know what they do.
I still say there's no better language for text processing, of which web presentation is one application subset.