I posted the following question on another thread:
"Does anybody know of a good solution that can be used from php that will effectively remove contact information like phone numbers, email addresses and maybe even contact addresses from a document?"
I quickly got told what I suspected... I am asking too much :)
So now I am looking for alternative solutions. One I am considering is using Amazon's Mechanical Turk to do the contact information removal.
So two question?
Would this be a good fit for mechanical turk?
How effective is the service?
Check out http://www.microtask.com. (I'm not affiliated with this company.)
You might be able to cast a wide net with your regular expressions and then have the human workers sift out the real addresses, phone numbers, and e-mail addresses. Whether "such-and-such" is an address, phone number, or e-mail address is a fairly straightforward question for a human.
Since they chop the form up (or say they do -- I haven't used it) you don't have as much to worry about privacy concerns, or may be able to justify them. If MicroTask has hundreds of clients, what they are able to do is take all of the microtasks and throw them in a giant hopper that randomizes which ones each individual worker sees. Hence, they could virtually guarantee that the workers will have almost no means to correlate any of the sensitive information they work on. Each worker would see thousands of independent pieces of information each day. Under these conditions, who would be able to discern that Task 347 on day 1 had the e-mail address that corresponds to Task 1133 on day 3? Even if they could, it's hardly worth it to them. They'll probably make more money just doing what is asked of them.
Related
This is an ongoing debate at my company. We run massive Adwords accounts. I need to automate adding or changing query string parameters on large numbers of keywords. Our SEM team is nervous that this could cause the Adwords editorial staff to disable large numbers of keywords while they review the changes (effectively killing traffic).
I can understand why changing the domain or page in the URL might cause this. But changing the query string should not, I would think.
Can anybody confirm/deny this possibility?
UPDATE 2013-03-19
I'm not sure this qualifies as an "answer". I posted this same question on Google Groups and, as usual, Google was noncommittal. However, this is what I have gathered so far (I'm sharing for posterity):
First of all, "editorial" doesn't seem to be a term that is widely accepted at Google. I'm saying this based on our discussions with our account reps. The term didn't mean much to them and required clarification. So, to clarify, when I say "editorial" I mean Google's process of reviewing your keyword term, ad copy, landing page, and potentially resetting statistics (quality score). This is mostly automated in their system from what I can tell. However, there are times when it appears that human beings actually get involved in the process.
And now the answer: It seems that modifying keyword destination URLs does not cause manual review nor reset of statistics. Possible exceptions are trademarked terms or pharmaceutical terms. I translate that more broadly as "any terms that have special rules".
NOTE: Folks in the Google Groups seem to all agree that modifying URLs at the Creative level DOES reset statistics. So tread carefully.
Here is the Google Group thread.
UPDATE 2013-07-11
I'm just talking to myself now. I feel so alone.
I just received the "tumbleweed" award for this post.
The Adwords team finally told us that modifying Destination URLS should not affect traffic.
So, we modified several hundred thousand Destination URLs and our SEM Team reported that some of their high volume keywords stopped getting traffic for about 10 days and then magically came back. No explanation. The Adwords team dug up some "expert" from the bowels of their staff and subsequently told us that modifying Destination URLs does affect traffic.
However, we were also transitioning these accounts to Enhanced Campaigns at the same time. So the results are inconclusive in my mind.
I don't think even the Adwords team knows how Adwords works.
It's cold here. Need to make a fire...
I am following verification and validation threads and I think an example might be helpful. I am not an experienced developer so I would like to know whether this would be correct:
User equirement: I want to be save my friend's name, address and phone number to the system
Software Requirement specification: User wants to be able to enter and save a name, address, phone number.
Technical analysis: web UI for data entering. Data will be saved into the SQL DB.
Detailed design: UI elements: 3 fields of a string type, 1 button, object XYZ, dbConnection....
Code: (actual code of UI, db scripts)
Is it like that? Could anyone correct or add what I am missing here?
As for verification, each phase can be verified against requirement (traceability). As for validation, the functional code should work as expected (save three attributes).
While this is some what theoretically true (I have to say this), it is completely wrong in all practical and real world scenarios.
Capture user needs and Why he wants to do a certain thing. This allows you to build just the software that user wants, eliminate waste that come as part of made-up requirements, technical requirements, nice to haves etc.
So instead of,
I want to be save my friend's name, address and phone number to the system...
I'd rather like to have the below which emphasizes Why? the real need of the user
I want to send a greeting card to my friend on his birthday.
Now, I know I just need his name and address. Since this is for future I also want to store this information. So what I write next is a set of acceptance criteria to meet the above customer needs. If I can capture these as a set of executable specifications then it is even better as those are verifiable programmatically.
Ignore everything else. Traceability is unnecessary overhead. We need it if we are building software based on fabricated requirements.
Read the below
Agile Manifesto
ATDD and BDD
Impact Mapping
I've never seen a good way to trace code to requirements outside a single sprint/time box. And also, you're missing testers from your list! Unless your testers are also your business analysts (I my experience professional testers find a lot of the requirements inconsistencies - aka bugs).
I think the best approach is to have everyone as involved as possible, so you can cross reference each person expectations often. If everyone works together, you don't need to implement a cargo-cult process where batches of information are transferred down stream in one way.
The simplest tool have traceability is your VCS, where each commit includes the ID of the user story/use case that the commit is related to.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Most sites at least employ server access log checking and banning along with some kind of bot prevention measure like a CAPTCHA (those messed-up text images).
The problem with CAPTCHAs is that they poss a threat to the user experience. Luckily they now come with user friendly features like refresh and audio versions.
Anyway, like linux vs windows, it isn't worth the time of a spammer to customize and/or build a script to handle a custom CAPTCHA example that only pertains to one site. Therefore, I was wondering if there might be better ways to handle the whole CAPTCHA thing.
In A Better CAPTCHA Peter Bromberg mentions that one way would be to convert the image to HTML and display it embedded in the page. On http://shiflett.org/ Chris simply asks users to type his name into an input. Examples like this are ways to simplifying the CAPTCHA experience while decreasing the value for spammers. Does anyone know of more good examples I could use or see any problem with the embedded image idea?
Image presented as HTML table is just a technical speed bump. There's no difficulty in extraction of pixels from such document.
IMHO CAPTCHA puts focus on a wrong thing – you're not interested whether there's a human on the other side. You wouldn't like human to spam you either. So take a step back and focus on spam:
Analyze text (look for spammy keywords, use bayesian filtering)
Analyze links (blacklist spammy domains – SURBL, LinkSleeve)
Look at traffic patterns and block floods
There's no single perfectly accurate method, but you can use few of them and weight the result to get pretty close.
Have a look at source code of Sblam! (it's a completely transparent server-side comment spam filter).
Alternatives to captchas are going to be to consider the problem from other angles. The reason for this is because captchas are built around the idea that a human and computer actor can be distinguished. As Artificial intelligence progresses, this will always become an increasingly difficult problem as the gap between computer and human users shrinks.
The technique used here on slashdot is for other users of the site to act as gatekeepers, marking abuse and removing offending posts before they become noticeable to a wide audience.
Another technique is to detect spam-like posts directly, using the same technology used to filter spam from email. Obviously it isn't 100% effective for email, and wont be for other uses, either, but if you can filter out 75% of the spam with very few false positives being filtered, then other techniques will only have to deal with the remaining 25%.
Keep a log of spam-related activity, so that you can track trends about offending ip addresses, content of posts, claimed user agent, and so forth, so that you can block abusive users at a routing level.
In nearly all cases, your users would rather put up with the slight inconvenience of abuse prevention, than the huge inconvenience of a major spam problem.
Ultimately, the arms race between you and spammers is one of cost-benefit. Initially, it will cost spammers close to nothing to spam your site, but you can change that to make it very difficult. Even if they continue to spam your site, the benefit they recieve will never grow beyond a few innocent users falling for their schemes. Once the cost of spamming rises sharply above the benefit, the spammers will go away.
Another way to benefit from that is to allow advertising on your site. Make it inexpensive (but not free, of course) and easy for legitimate advertisers to post responsible marketing material for your users to see. Would be spammers may find that it is a better deal to just pay you a few dollars and get their offering seen than to pursue clandestine methods.
Obviously most spammers won't fit in this category, since that is often more about getting your users to fall victim to malware exploits. You can do your part for that by encouring users to use modern, up to date browsers or plugins so that they become less vulnerable to those same exploits.
This article describes a technique based on hashed field names (changing with each page view) with some of them being honeypot fields (i.e. the request is rejected if they're filled) that are hidden from human users via various techniques.
Basically, it relies on spam scripts not being sophisticated enough to determine which form fields are actually visible. In a way, that is a CAPTCHA, since in order to solve it reliably, not only would they have to implement HTML, CSS and JavaScript fully, they'd also have to recognize when a field is too small to see, colored the same as the background, hidden behind another field, placed outside the browser's viewport, etc.
It's the same basic problem that makes Web Standards a farce: there is no algorithm to determine whether a webpage "looks right" - only a human can decide that.
seen this?
It's a system with cute pictures instead of captcha ;)
But I still think honeypots are a better solution - they're so cheap&easy&invisible
I really think that Dinah hit the nail on the head. The fact seems to be that the beauty of the whole CAPTCHA setup is that there is no standard. Standardizing would only help the market to be more profitable.
Therefore it seems that the best way to handle the CAPTCHA problem is to come up with a fairly hard system for bots to catch that is NOT used by anyone else on the planet. It could be a question system, a very custom image creator, or even a mix of JS calls that only browsers respect.
By the time that your site is big enough for spammers to care you should have the budget to rethink your CAPTCHA setup and optimize it much more. In the mean time we should be monitoring our server logs and banning bad agents, refers, and IP's.
In my case I created a CAPTCHA image that I believe is very different from any other CAPTCHA I have seen. This should do fine for now along side my Apache logs + htaccess banning and Aksimet checking. Maybe I should spend time on a reporting feature as well.
although not a true image captcha, good turing test is asking users a random question - common options are: is ice hot or cold? 5+2= ..? etc.
I am developing an online site to which access will be sold at college bookstores. Students will purchase a card at the bookstore with an access code that they may then use to register online at our site.
I want to make the code as user friendly as possible. I personally hate registering for a product and having to type in a registration key 5 times because it's ambiguous.
Can anyone point me to resources describing best practices for designing the format of the code itself? Obvious things spring to mind-- don't use zeroes or the letter O, don't make it case sensitive, include some kind of checksum. I don't want to be creative here, I need a recipe for what must be a problem solved many times.
Joel Spolsky had some good insights to solving this problem in one of the recent StackOverflow podcasts. I believe the episode was #49, you should download podcasts or checkout the transcripts at https://stackoverflow.fogbugz.com/default.asp?W4
Dealing with 0 (number) and O (letter) mixed in a key is really annoying as some fonts make it hard to distinguish the two.
Other usability concepts such as groups of three being easier to deal with and remember then a single number are good to be aware of. For example, 345-829-817-432 instead of 345829817432.
By the way, 345-829-817-432 gives you 12^10 permutations, and even the smaller number 345-829-817 gives you 9^10 permutations which may give you enough strength depending on your situation.
tschüss,
bn
It really depends on how much security you need. A few ideas come to mind.
If you want something really simple you could generate simulated credit card numbers; students are adept at using these four-digit combinations, and they can be checked with a Luhn algorithm.
If you want something a little stronger you could generate a GUID, and use that as the code.
If your website can send emails you can ask the student for their email address, and send them a challenge/response email. Then you don't need codes at all. Their email address is the code.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
How can our team gather requirements from our "Product Owner" in as low friction yet useable of a way as possible?
Now here's the guidelines- No posts that it can't be done or that the business needs to make a decision that it cares about quality, yada yada. The product I work for is a small group that has been successful for years. I just want to help them step it up a notch.
Basically, I'm on a 6 or 7 person team with one Product Owner. She does a great job but is juggling a few different roles (as I believe is common on extremely small teams). Usually requirements are given at sporadic times (email convos, face to face discussions, meetings, etc). They are never entered into a system and sometimes this results in features missing a release or the release getting pushed back since everyone forgot about the necessary feature.
If you're in a similar situation but you found a way to overcome this, I'd love to hear it. I'm happy to write code to help ease this situation but it can't be a web site that the Product Owner has to go to in order to get anything done. She is extremely busy and we need some way of working together as a team in order to gather these requirements.
I'm currently thinking of something like this: Developers and team members gather requirements discussed in face to face meetings and write some quick notes on the features discussed on a wiki page. Product owner is notified whenever these pages are updated and it then becomes her responsibility to ensure accuracy.
Pros: We'll have some record of the features. Cons: The developers are taking responsibility for something that they ordinarily wouldn't. I'm okay with that here. I think in this situation it's teamwork.
Of course once we do this, then we're going to see that the product owner probably doesn't have enough time to ensure feature accuracy. Ultimately she is overburdened and I think this will help showcase that fact, but I just need to be able to draw attention to that first.
So any suggestions?
P.S. her time is extremely limited so it is considered unreasonable to expect her to need to type in the requirements after discussion. She only has time to discuss them once and move on.
Although the concept of "product owner" is a littl ambiguous to me, I think I am working in very similar circumstances: the customer is extremely buzy and always is a bottleneck in developing requirements.
On the surface, what we try to do in this situation is quite obvious and seemingly simple: we try to make sure that the customer is involved in "read-only / talk-only" mode. No writing. Minimum reading. Mostly talking.
The devil, of course, is in details. So, here are some specifics about our process (in no particular order):
We often start from recording problem statements, which are the ultimate sources of requirements. In fact, sometimes a problem statement is all that we record initially, just to make sure it does not get lost.
NB: It is important to distinguish problem statements from requirements. Although a problem statement sometimes clearly implies some requirement, in general a single problem statement may yield a whole bunch of requirements (each having its own severity and priority); moreover, sometimes a given requirement my define a solution (usually just a partial one) to multiple problems.
One of the main reasons of recording problem statements (and this is very relevant to your question!) is that semantically they are somewhat "closer to the customer's skin" and more stable than requirements derived from them. I believe those problem statements make it much easier and quicker to put the customer into proper context whenever he has time to provide feedback to the development team.
We do record all the requirements (and back-track them to problem statements), regardless of when are we going to implement them. Priorities govern the order in which requirements get implemented. Of course, they also govern the order in which customer reviews unfinished requirements.
NB: A single fat document containing all requirements is an absolute no-no! All the requirements are placed in "problem tracking database", along with bug reports. (A bug is just a special case of a problem in our book.)
We always try to do our best to minimize the number of iterations necessary to "finalize" each requirement (or a group of related requirements). Ideally, a customer should have to review a requirement only once.
Whenever the first review turns out to be insufficient (happens all the time), and the requirement in question is complex enough to require a lot of text and/or illustrations, we make sure that the customer does not have to re-read everything from scratch. All the important changes/additions/deletions since the previous reviwed version are highlighted.
While a problem or requirement remains in an unfinished state, all the open issues (mostly questions to customer) are embedded into the document and highlighted. As a result, whenever the customer has time to review requirements, he does not have to call a meeting and solicit questions from the team; instead the customer can open any unfinished document first, see what exactly is expected from him, and then decide what's the best way and time (for him) to address any of the open issues. Sometimes the customer chooses to write a email or add a comment directly to the problem document.
We try our best to establish and maintain official domain vocabulary (even if it gets scattered across the documentation). Most importantly, we practically force the customer to stick to that vocabulary.
NB: This is one of the most difficult parts of the process, and customer tries to "rebel" from time to time. However, at the end of the day everybody agrees that it is the only way to make precious meetings with the customer as efficient as possible. If you ever attended one-hour meetings where 30 minutes were being spent just to get everybody on the same page (again), I'm sure you would appreciate having a vocabulary.
NB: Whenever possible, any changes in the official vocabulary get reflected in the very next release of the software.
Sometimes, a given problem can be solved in multiple ways, and the right choice is not obvious without consulting with the customer. It means that there will be a "menu of requirements" for the customer to pick from. We document such "menus", not just the finally chosen requirement.
This may seem controversial and look like an unnecessary overhead. However, this approach saves a lot of time whenever the customer (usually few weeks or months down the road) suddenly jumps in with a question like "why the heck did we do it this way and not that way?" Also, it is not such a big deal to hide "rejected branches" using proper organization/formatting of requirements documentation. Boring but doable. :-)
NB: When preparing "menus of requirements", it is very important not to overdo them. Too many choices or too many choice nesting levels - and the next review may require much more customer's time than really necessary. Needless to say that the time spent on elaborated branches may be totally wasted. Yes, it is difficult to find some balance here (it greatly depends on the always-in-a-hurry customer's ability to think two or more steps ahead and do it quickly). But, what can I say? If you really want to do your job well, I am sure that after some time you will find the right balance. :-)
Our customer is a very "visual" guy. Therefore, whenever we discuss any significant user interface elements, screen mockups (or even lightweight prototypes) often are extremely helpful. Real time savers sometimes!
NB: We do screen mockups exclusively for the customer, only in order to facilitate discussions. They may be used by developers too, but in no way do they substitute user interface specifications! More often than not, there are some very important UI details that get specified in writing (now - primarily for developers).
We are lucky enough to have a customer with a very technical background. So we do not hesitate to use UML diagrams as discussion aid. All kinds of UML diagrams - as long as they help customer to get into proper context quicker and stay there.
I am talking about requirements-level UML diagrams, of course. Not about implementation-level ones. I believe that even not very technical people can start digging requirements-level UML diagrams sooner or later; you just have to be patient and know what to put on a diagram.
Obviously, the cost of such process greatly depends on analytical and writing skills of the team, and of course on the tools that you have at your disposal. And I must admit that in our case this process appears to be quite expensive and slow. But, taking into account the very low rate of bugs and low rate of "vapor-features"... I think, in the long run, we get very good payback.
FWIW: According to Joel's nice classification of software products, this project is an "internal" one. So we can afford to be as agile as our customer can handle. :-)
"Developers and team members gather requirements discussed in face to face meetings and write some quick notes"
Start with that. If you aren't taking notes, just make one small change. Take Notes. Later, you might post them to a wiki or create a feature backlog or start using Scrum or bugzilla or something.
First, however, make small changes. Write stuff down sounds like something you're not doing, so just do that and see what improves and what you can do next. Be Agile. Work Incrementally.
You might want to be careful of the HiPPO in the room. The Highest Paid Person's Opinion is not always a good one. We've tended to focus more on providing great tools and support for developers. These things, done right, take some of the hassle out of development, so that it becomes faster and more fun. Developers are then more flexible in terms of their workload, and more amenable to late-breaking changes.
One-Click testing and deployment are a couple of good ones to start with; make sure every developer can run up their own software stack in a few seconds and try out ideas directly. Developers are then able to make revisions quickly or run down side paths they find interesting, and these paths are often the most successful. And by successful I mean measured success based on real metrics gathered right in the system and made readily available to all concerned. The owner is then able to set the metrics, which they probably care about, rather than the requirements, which they either don't care about or have no experience in defining.
Of course it depends on the owner and your particular situation, but we've found that metrics are easier to discuss than requirements, and that developers are pretty good at interpreting them too. A typical problem might be that customers seem to spend a long time filling their shopping carts but don't go on to checkout.
1) A marketing requirement might be to make the checkout button bigger and redder. 2) The CEO's requirement might be to take the customer straight to checkout, as the CEO only ever buys one item at a time anyway. 3) The UI designer's requirement might be to place a second checkout button at the top of the cart as well as the existing one at the bottom. 4) The developer's requirement might be some Web 2.0 AJAX widget that follows the mouse pointer around the screen. Who's right?
Who cares... the customer probably saw the ridiculous cost of delivery and ran away. But redefine the problem as a metric, instead of a requirement, and suddenly the developer becomes interested. The developer doesn't have to do 10 rounds with the CMO on what shade of red the button should be. He can play with his Web 2.0 thing all week, and then rush off the other 3 solutions on Monday morning. Each one gets deployed live for 48 hours and the cart-to-checkout rate gets measured and reported instantly. None of it makes any difference, but the developer got to do their job and the business shifts it's focus onto the crappy products they sell and the price they gauge on delivery.
Well, ok, so the example is contrived. There's a lot of work in there to make sure that the project is small, the team is experienced, hot deployment is simple, instant rollback is provided, and that everyone's on board. What we wanted to get to is a state where the developer's full potential is not wasted, so that's why they're involved not just from the start, but also in the success. Start out with an issue like the number of clicks during registration is too high, run it through a design committee, and we found that the number of clicks actually went up in the design specification. That was our experience anyway. But leave the developer some freedom to just reduce the number of clicks and you might actually end up with a patented solution, as we did. Not that the developer cares about patents, but it had merit - and no clicks!