All the diagnosis information and messages are presented through the Google Webmaster Tools UI, not through email. There is an option in Webmaster Tools to forward messages to email, but this is opt-in.
You have a point though...there are lots of "from google" false emails floating around. As you know it's a tough problem to solve:/
This is a great service. Google should set up an opt-in email notification as well.
It helps the webmasters build better sites and teaches them to check the Google website tools that allow them to groom their site for best indexing on Google. That's great.
I was about to slam you on the basis that international calls from a cellphone are traditionally very expensive. However, it looks like for $5/month, tmobile offers competitive discount international calls:
In other words, the core ideas come quick, and all the fine details take much longer.
I totally agree. Back in the day, I remember Randy Pausch (who started the whole "game" prototyping process mentioned in the article) lecturing at a few of us coders for spending too much time making code re-usable. He said that code-reuse is good and all, but not in the context of prototyping and testing out ideas.
I remember shocked whispers throughout the lab: "did he just tell us to write ugly code???".
The prototyping method from the article has been around for a while at CMU, since about 1998 in a class called "Building Virtual Worlds". The whole theory is to get people to think creatively by giving them a central idea, a bunch of constraints, and an even bigger set of tools to play with.
The process is actually intended to NOT be perfect. The idea is for people to quickly design an idea, then sketch out the idea in code using prototype tools, then test it out in front of an audience, all in a week. The interesting part is when people start building on ideas from projects that are showcased. The good ideas are repeated and built on, and others are archived.
Think about this though...given a few simple constraints, you can do ANYTHING you want. It basically becomes a weekly cycle of playing, where on review the interesting parts are noted and you move on to the next play session.
I agree, some ideas take years of creating and planning, building. But, this process is never clean. The very best ideas are usually grown through quick iterations and experimentation, which Randy Pausch's process forces pretty well.
You can ask anyone who's taken "Building Virtual Worlds" or been in the ET program at CMU. They'll bitch about the crazy stunts they had to pull to get something working (imagine collision detection suddenly going kaput an hour before show-and-tell time) but there was no doubt that it was non-stop creativity.
If you're referring to the x windows highlight-copy and middle-button-click-paste, it's a bad idea in terms of usability. I'm not saying it's horrible, but it goes wrong with everyday users because the act of highlighting blows away what's in the the buffer. I have a hard time believing that users would have loved it.
Ajax is one single function: XMLHttpRequest, a extension to the browser DOM invented by MS. In other words its a propierty hack on the browser API, nothing more.
In the old days we'd use javascript to dynamically create an iframe on the client, set the onload callback and src attribute, and got whatever data we wanted. We liked it, too.
The modal issue I'm referring to isn't really about discrete modes like in Vi. I'll refer back to the wikipedia entry:
""An human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user's locus of attention and (2) the interface will execute one among several different responses to the gesture, depending on the system's current state.
In the case of undo history, the current locus of the user's attention is the image, not memory constraints. When undoing a series of actions, the ideal response as you suggested is to have no limits on undo history. This obviously isn't feasible, so what's the next best option? Having a fixed number of undo operations in this case is at least predictable, compared with the variable number of operations when it's dependent on image size and how much disk is available.
I don't personally know anyone (personally, anyway) that works on the photoshop team, but I would be willing to bet that they chose 20 based on user observation. I'm pretty sure they designed and prototyped an unlimited undo, but chose to budget their development time elsewhere. I doubt they chose 20 out of a hat out of laziness (although software developers are universally lazy to some extent, right?).
So from a development perspective I do like how gimp's undo history is only limited by disk space. It's definitely more flexible/powerful than photoshop undo. I just think it could be better designed. If it's going to be limited by diskspace then the undo window should show a how much "undo" space is available, and offer the choice to reclaim space beyond a certain point. Yes, I know this is configurable in preferences (min, max, tile cache size, etc), but this is tedious. Just expose the control right next to the information that it's constraining. Photoshop is guilty of this as well in some cases, so Adobe isn't off the hook either.
But all this takes extra dev time, QA, usability testing, etc. In the end it comes down to product design choices, and it's clear that Adobe went the more simple route and focused resources on other features.
Sheesh. You're really stretching to find a reason. It doesn't do it because Adobe hasn't put it in. And the reason they haven't is probably because there's not a lot of call for it. That seems like a perfectly reasonable answer.
He's not stretching. It's generally a good idea to avoid modes when designing UIs.
Modes are generally frowned upon in interface design because they inevitably lead to input errors, known as mode errors, when the user forgets what state the interface is in. Interface guru Jef Raskin came out strongly against modes, writing, "Modes are a significant source of errors, confusion, unnecessary restrictions, and complexity in interfaces." Later he notes, "'It is no accident that swearing is denoted by #&%!#$&,' writes my colleague, Dr. James Winter; it is 'what a typewriter used to do when you typed numbers when the Caps Lock was engaged'."
I don't know what university you went to. If you worked during the term at the one I attended, you would fail. Guaranteed. You cannot pass that course without spending the majority of your term-time studying.
I don't quite believe this. I knew plenty of graduates from some of the most challenging engineering schools in the US (including the one I attended) who found plenty of time for either part-time dev-work, a research project (helping out a professor/dept), or a personal side project. I don't have any supporting data, but I would even wager that graduates of tougher schools tend to have more non-academic experience than those coming from other schools.
Regardless, I'll assume what you say is true. If so, then the herculean effort required to get through such a demanding curriculum would definitely have a lot of output to show for it, such as implementing your own DBMS, OS kernel, networking stack, or even applications. I can't imagine that your curriculum was so theory-intensive that there was no time to actually produce anything. Even if it were so theory intensive, there are always internship or co-op opportunities. Even if there is no formal university career center, all it takes is a chat with a professor or recent graduate to find a job.
There are two ways that most people get their early jobs in this field:
- nepotism
- lying in interviews
If the first is not an option and you aren't willing to do the second, you will typically finish your degree having attempted to get
several summer jobs and been turned down for all of them, and find that nobody's interested in hiring you now either.
What about....
- college career centers
- job fairs (both university and industry)
- professional/hobbyist groups with local representation (ACM, linux user groups, Java user groups)
- Recent grads (you did drink with some of the older people at parties, right?)
- friends and (yes) family
- Working for free (demo/portfolio material) for non-profits and small orgs?
I'm not trivializing the ability to get a job -- it's one of the hardest and soul-wrenching tasks out there. All I'm trying to say is that there is always more that one can do, and that it's rare than anyone is truely stuck.
Consider yourself lucky. Either that, or you're a pro at maintaining an XP install. Most of the XP users in my office complain of the same problems with suspend/hibernate, and are slowly switching to MacBook Pros. This has been the case with every other job I've had. I loved my old Thinkpad, and the suspend/hibernate worked moderately well, but it's not nearly as smooth as a Powerbook. It literally does take 2-3 seconds to get back to work wherever you left off.
Except it is the roll of the dice. It is true that some people are better at convincing other people that they have a better hand, but the end of every poker tournament is who gets the better cards. Every time. Never has anyone ever folded the last of their money because the other guy has presented the idea that he has a better hand.
Bluffing isn't the only other part of poker strategy. Making good value bets, hand-reading (ie. observing betting patterns to deduce opponent strength), manipulating the dynamics of multiple players involved in a pot, knowing when to get involved and uninvolved...I mean the list goes on. In tournament play things things like game theory come even more into play. In your particular example, yes, the winner is determined by a single final best hand, but consider all the events that lead up to that point. One player may have in particular outplayed the other, or induced the opponent to play sub-optimally, or commanded such a huge chip lead that the cards don't even matter (ie the range of strategy for the smaller stack narrower than the bigger stack). And yes, there's luck, which to some people is what makes the game so interesting.
The machines in the US are heavily regulated and while they are "settable" for payout there is considerable oversight as to how they are set. Why would you assume you are getting a fair shake on games like that?
I'm a little confused. Those games ARE already rigged. Casino players playing player-vs-house table games and slot machines are always getting the worse odds. Those games are clearly and openly in favor of the house, whether it's a 1% edge or 48% (and there are games with that high of a house edge). Why would you assume that players are getting a fair shake in these games anywhere, whether in brick-and-mortar or online? People clearly play these games for the thrill and entertainment value, not for purposes of making money, so they should be allowed to dispense of their income in any way that they choose.
Poker is a little different -- although from observation it appears that most people would stand a better chance playing slots than to sit down at table full of skilled players.
On the other, the online gambling industry is one that is notoriously rife with fraud, and it's entirely possible that these guys are scum that have been doing what they're accused of or worse.
While it's possible that there are some shady businesses with online gambling, particularly in the referral/affiliate ring, what examples are you referring to when you say that it's "notoriously rife with fraud"? I agree there are some edgy business practices in the past, and I know specifically of a gambling site in the past that went belly-up and afterwards refused to pay back depositor's money. In the last 2 years, however, the well-known online poker rooms seem to be very trustworthy -- and it's in their best interest to do so, just as it has been in the best interest of brick-and-mortar casinos to run a clean operation.
There are also a number of "person vs house" table games where the odds are so narrowly in the houses favor that one can pretty easily win in the very short term, if you follow very strict rules when to stop, or in the long term. Those games work for the casino because 99% of the people who play them don't play them well.
This statement makes no sense. How is it easy to win in the short term? How do you define short term, and what are the rules to stop? Stopping a session when you're ahead, and repeating this process doesn't make it a winning game in the long run. This reminds me of being in a cardroom, watching a hot-shot sit down, win a few pots, and then leave because he figures his luck has run out and he's bound to lose the next few hands.
Well said. I haven't seen the Mozilla codebase, but I tend to take "that codebase is horrible" statements with a grain of salt. To all professional developers...have you ever noticed the chief architect or senior tech lead or other technical leaders ever dismiss an entire codebase.
Any professional developer should print the paragraph below out.
-- snip --
I work with the code every day. It is complicated, yes, but that doesn't necessarily mean it is all badly written. I think you probably don't understand the reason for the complexity, and therefore you incorrectly consider it to be terrible code. I'm not saying we don't have some bad code in there, but to say what you are saying about the entire codebase is very naive.
Yes we are probably arguing semantics here, however....
My working definition of Quality is the degree to which implementation meets requirements and expectations. I agree, proof of concept differs from scalable/maintainable/etc, but this can and should be stated up front. Software should absolutely not be scalable or fault tolerant if not demanded by requirements. If a company is making an attempt to ship proof of concept software, it is just as much the fault of the programmer or development staff for not communicating this properly.
To re-iterate, quality is a constant. Yes, up front stated, intended functionality dictates some of the process to ensure quality. But process aspects like configuration management, unit testing, codereview, etc should be a given regardless of the nature of the project. Why the hell would any professional release software that does not live up to expectations and requirements, ever?
tell them they can have any two of these options: (A) fast, (B) cheap, (C) good. Chances are, they will understand that a quality implementation takes more time.
I don't know where you heard of A, B, and C but I think you have the concept mistaken. The three typical competing priorities in a software project are the following:
Schedule
Functionality
Cost/Resources
You may notice that quality is NOT a variable. That isn't to say that software professionals shouldn't care about quality. Rather, quality should NEVER be compromised. If you are taking shortcuts in quality, you are only hurting yourself. Furthermore, research has shown that low quality will directly impact schedule, availability of functionality, and cost. A quality implementation should not take more time, as any short-term gains you have for shortcutting quality only causes significant issues downstream. Quality is also largely determined by process and discipline, not how "good" a programmer is or how much effort is contributed.
Also, is our responsibility as software professionals to communicate and enforce this concept with our colleagues, clients, and superiors. To be clear, this concept applies to build software with actual lifecycle, delivery expectations, and resource requirements. The odd perl script, exploratory coding (eg. I'm going to play around with ruby on rails this afternoon), and R&D activities have an entirely different context and thus, different rules apply.
To the original poster:
One way you can manage these competing priorities above is to always be in control of one. If your "customers" (using the term in a broad sense) require feature set X with schedule Y, then demand that you can make the adjustments you need with cost. If resources are fixed and they need delivery in 3 months, you require control of functionality to deliver (ie. take out features). Use this concept as a tool for compromise and negotiation. If your customers object and don't believe you, tell them that this is is an accepted software engineering concept: they can either try their luck squeezing, or actually have something at the end of the day that will work. The great thing about using competing priorities as a model, however, is that both you and your customers have points of control, which ultimately is what you both want in order to project goals through.
Definitely interesting but impractical.
First off, contrast goes out the window unless you can control lighting conditions. Secondly, flat white surfaces aren't that easy to find. You'd look like a tool throwing the projection against the back of an airplane seat. Also, while it's tiny it's a separate unit, which means you'll need to bring around a playback device and cables.
The projector does look awesome for other applications, however. I'd love to have one of these in the office for impromptu reviews.
Slashdot Mirror
All the diagnosis information and messages are presented through the Google Webmaster Tools UI, not through email. There is an option in Webmaster Tools to forward messages to email, but this is opt-in.
You have a point though...there are lots of "from google" false emails floating around. As you know it's a tough problem to solve :/
This is a great service. Google should set up an opt-in email notification as well.
It helps the webmasters build better sites and teaches them to check the Google website tools that allow them to groom their site for best indexing on Google. That's great.
Webmaster Tools has opt-in email notification. Here are details: http://googlewebmastercentral.blogspot.com/2009/06/to-make-webmaster-tools-message-center.html
The "Malware details" feature (mentioned in the article), however, doesn't send you any notifications just yet.
mod parent up. great summary.
Personally I use Skype-To-Go from my phone to call my family overseas.
http://www.t-mobile.com/International/LongDistanceOverview.aspx
Skype rates are about the same (also with a small per-month fee): http://www.skype.com/intl/en/prices/callrates/
In other words, the core ideas come quick, and all the fine details take much longer.
I totally agree. Back in the day, I remember Randy Pausch (who started the whole "game" prototyping process mentioned in the article) lecturing at a few of us coders for spending too much time making code re-usable. He said that code-reuse is good and all, but not in the context of prototyping and testing out ideas.
I remember shocked whispers throughout the lab: "did he just tell us to write ugly code???".
The prototyping method from the article has been around for a while at CMU, since about 1998 in a class called "Building Virtual Worlds". The whole theory is to get people to think creatively by giving them a central idea, a bunch of constraints, and an even bigger set of tools to play with.
The process is actually intended to NOT be perfect. The idea is for people to quickly design an idea, then sketch out the idea in code using prototype tools, then test it out in front of an audience, all in a week. The interesting part is when people start building on ideas from projects that are showcased. The good ideas are repeated and built on, and others are archived.
Think about this though...given a few simple constraints, you can do ANYTHING you want. It basically becomes a weekly cycle of playing, where on review the interesting parts are noted and you move on to the next play session.
I agree, some ideas take years of creating and planning, building. But, this process is never clean. The very best ideas are usually grown through quick iterations and experimentation, which Randy Pausch's process forces pretty well.
You can ask anyone who's taken "Building Virtual Worlds" or been in the ET program at CMU. They'll bitch about the crazy stunts they had to pull to get something working (imagine collision detection suddenly going kaput an hour before show-and-tell time) but there was no doubt that it was non-stop creativity.
If you're referring to the x windows highlight-copy and middle-button-click-paste, it's a bad idea in terms of usability. I'm not saying it's horrible, but it goes wrong with everyday users because the act of highlighting blows away what's in the the buffer. I have a hard time believing that users would have loved it.
Ajax is one single function: XMLHttpRequest, a extension to the browser DOM invented by MS. In other words its a propierty hack on the browser API, nothing more.
In the old days we'd use javascript to dynamically create an iframe on the client, set the onload callback and src attribute, and got whatever data we wanted. We liked it, too.
The modal issue I'm referring to isn't really about discrete modes like in Vi. I'll refer back to the wikipedia entry:
In the case of undo history, the current locus of the user's attention is the image, not memory constraints. When undoing a series of actions, the ideal response as you suggested is to have no limits on undo history. This obviously isn't feasible, so what's the next best option? Having a fixed number of undo operations in this case is at least predictable, compared with the variable number of operations when it's dependent on image size and how much disk is available.
I don't personally know anyone (personally, anyway) that works on the photoshop team, but I would be willing to bet that they chose 20 based on user observation. I'm pretty sure they designed and prototyped an unlimited undo, but chose to budget their development time elsewhere. I doubt they chose 20 out of a hat out of laziness (although software developers are universally lazy to some extent, right?).
So from a development perspective I do like how gimp's undo history is only limited by disk space. It's definitely more flexible/powerful than photoshop undo. I just think it could be better designed. If it's going to be limited by diskspace then the undo window should show a how much "undo" space is available, and offer the choice to reclaim space beyond a certain point. Yes, I know this is configurable in preferences (min, max, tile cache size, etc), but this is tedious. Just expose the control right next to the information that it's constraining. Photoshop is guilty of this as well in some cases, so Adobe isn't off the hook either.
But all this takes extra dev time, QA, usability testing, etc. In the end it comes down to product design choices, and it's clear that Adobe went the more simple route and focused resources on other features.
He's not stretching. It's generally a good idea to avoid modes when designing UIs.
From http://en.wikipedia.org/wiki/Mode_(computer_interface):
Because unlike programmers and more tech-minded types, designers don't really like to think about memory usage and tweaking data structures.
I don't quite believe this. I knew plenty of graduates from some of the most challenging engineering schools in the US (including the one I attended) who found plenty of time for either part-time dev-work, a research project (helping out a professor/dept), or a personal side project. I don't have any supporting data, but I would even wager that graduates of tougher schools tend to have more non-academic experience than those coming from other schools.
Regardless, I'll assume what you say is true. If so, then the herculean effort required to get through such a demanding curriculum would definitely have a lot of output to show for it, such as implementing your own DBMS, OS kernel, networking stack, or even applications. I can't imagine that your curriculum was so theory-intensive that there was no time to actually produce anything. Even if it were so theory intensive, there are always internship or co-op opportunities. Even if there is no formal university career center, all it takes is a chat with a professor or recent graduate to find a job.
There are two ways that most people get their early jobs in this field:
- nepotism
- lying in interviews
If the first is not an option and you aren't willing to do the second, you will typically finish your degree having attempted to get several summer jobs and been turned down for all of them, and find that nobody's interested in hiring you now either.
What about....
- college career centers
- job fairs (both university and industry)
- professional/hobbyist groups with local representation (ACM, linux user groups, Java user groups)
- Recent grads (you did drink with some of the older people at parties, right?)
- friends and (yes) family
- Working for free (demo/portfolio material) for non-profits and small orgs?
I'm not trivializing the ability to get a job -- it's one of the hardest and soul-wrenching tasks out there. All I'm trying to say is that there is always more that one can do, and that it's rare than anyone is truely stuck.
Consider yourself lucky. Either that, or you're a pro at maintaining an XP install. Most of the XP users in my office complain of the same problems with suspend/hibernate, and are slowly switching to MacBook Pros. This has been the case with every other job I've had. I loved my old Thinkpad, and the suspend/hibernate worked moderately well, but it's not nearly as smooth as a Powerbook. It literally does take 2-3 seconds to get back to work wherever you left off.
I think you've been fooled. That 40-year-old just happens to look 29.
Except it is the roll of the dice. It is true that some people are better at convincing other people that they have a better hand, but the end of every poker tournament is who gets the better cards. Every time. Never has anyone ever folded the last of their money because the other guy has presented the idea that he has a better hand.
Bluffing isn't the only other part of poker strategy. Making good value bets, hand-reading (ie. observing betting patterns to deduce opponent strength), manipulating the dynamics of multiple players involved in a pot, knowing when to get involved and uninvolved...I mean the list goes on. In tournament play things things like game theory come even more into play. In your particular example, yes, the winner is determined by a single final best hand, but consider all the events that lead up to that point. One player may have in particular outplayed the other, or induced the opponent to play sub-optimally, or commanded such a huge chip lead that the cards don't even matter (ie the range of strategy for the smaller stack narrower than the bigger stack). And yes, there's luck, which to some people is what makes the game so interesting.
The machines in the US are heavily regulated and while they are "settable" for payout there is considerable oversight as to how they are set. Why would you assume you are getting a fair shake on games like that?
I'm a little confused. Those games ARE already rigged. Casino players playing player-vs-house table games and slot machines are always getting the worse odds. Those games are clearly and openly in favor of the house, whether it's a 1% edge or 48% (and there are games with that high of a house edge). Why would you assume that players are getting a fair shake in these games anywhere, whether in brick-and-mortar or online? People clearly play these games for the thrill and entertainment value, not for purposes of making money, so they should be allowed to dispense of their income in any way that they choose.
Poker is a little different -- although from observation it appears that most people would stand a better chance playing slots than to sit down at table full of skilled players.
While it's possible that there are some shady businesses with online gambling, particularly in the referral/affiliate ring, what examples are you referring to when you say that it's "notoriously rife with fraud"? I agree there are some edgy business practices in the past, and I know specifically of a gambling site in the past that went belly-up and afterwards refused to pay back depositor's money. In the last 2 years, however, the well-known online poker rooms seem to be very trustworthy -- and it's in their best interest to do so, just as it has been in the best interest of brick-and-mortar casinos to run a clean operation.
This statement makes no sense. How is it easy to win in the short term? How do you define short term, and what are the rules to stop? Stopping a session when you're ahead, and repeating this process doesn't make it a winning game in the long run. This reminds me of being in a cardroom, watching a hot-shot sit down, win a few pots, and then leave because he figures his luck has run out and he's bound to lose the next few hands.
this is great
Any professional developer should print the paragraph below out.
-- snip -- I work with the code every day. It is complicated, yes, but that doesn't necessarily mean it is all badly written. I think you probably don't understand the reason for the complexity, and therefore you incorrectly consider it to be terrible code. I'm not saying we don't have some bad code in there, but to say what you are saying about the entire codebase is very naive.
Most if not all of of Michaelangelo's famous creations were paid-for products.
My working definition of Quality is the degree to which implementation meets requirements and expectations. I agree, proof of concept differs from scalable/maintainable/etc, but this can and should be stated up front. Software should absolutely not be scalable or fault tolerant if not demanded by requirements. If a company is making an attempt to ship proof of concept software, it is just as much the fault of the programmer or development staff for not communicating this properly.
To re-iterate, quality is a constant. Yes, up front stated, intended functionality dictates some of the process to ensure quality. But process aspects like configuration management, unit testing, codereview, etc should be a given regardless of the nature of the project. Why the hell would any professional release software that does not live up to expectations and requirements, ever?
I don't know where you heard of A, B, and C but I think you have the concept mistaken. The three typical competing priorities in a software project are the following:
You may notice that quality is NOT a variable. That isn't to say that software professionals shouldn't care about quality. Rather, quality should NEVER be compromised. If you are taking shortcuts in quality, you are only hurting yourself. Furthermore, research has shown that low quality will directly impact schedule, availability of functionality, and cost. A quality implementation should not take more time, as any short-term gains you have for shortcutting quality only causes significant issues downstream. Quality is also largely determined by process and discipline, not how "good" a programmer is or how much effort is contributed.
Also, is our responsibility as software professionals to communicate and enforce this concept with our colleagues, clients, and superiors. To be clear, this concept applies to build software with actual lifecycle, delivery expectations, and resource requirements. The odd perl script, exploratory coding (eg. I'm going to play around with ruby on rails this afternoon), and R&D activities have an entirely different context and thus, different rules apply.
To the original poster:
One way you can manage these competing priorities above is to always be in control of one. If your "customers" (using the term in a broad sense) require feature set X with schedule Y, then demand that you can make the adjustments you need with cost. If resources are fixed and they need delivery in 3 months, you require control of functionality to deliver (ie. take out features). Use this concept as a tool for compromise and negotiation. If your customers object and don't believe you, tell them that this is is an accepted software engineering concept: they can either try their luck squeezing, or actually have something at the end of the day that will work. The great thing about using competing priorities as a model, however, is that both you and your customers have points of control, which ultimately is what you both want in order to project goals through.
Definitely interesting but impractical. First off, contrast goes out the window unless you can control lighting conditions. Secondly, flat white surfaces aren't that easy to find. You'd look like a tool throwing the projection against the back of an airplane seat. Also, while it's tiny it's a separate unit, which means you'll need to bring around a playback device and cables. The projector does look awesome for other applications, however. I'd love to have one of these in the office for impromptu reviews.