If a customer discovers a bug, who created it?
2,100 karma · joined July 14, 2014
"Modern processors can process more instructions in a month than there are seconds in the age of the universe."
Both Intel and AMD have processors which can process over 300,000 MIPS [1], that's 300 billion IPS.
Universe age in seconds = (13,820,000,000 * 365 * 24 * 60 * 60) = 4.35828E+17
instructions per day = (300,000,000,000 * 24 * 60 * 60) = 2.592E+16
Universe age in seconds / instructions per day = ~16.8 days to process as many instructions as there have been seconds
1000000 (microseconds/second) * 60 (sec/min) * 30 (min for a half hour) = 1800000000
10^9= 1000000000
#66 says: "If no one ever finds out about the bug then the bug never existed in the first place."
While the outcome is the same, it doesn't literally mean the bug never existed. The existence of a bug is orthogonal to its discovery. Its discovery does not bring about its existence.
Do you have any data for #93? I'd expect a power log distribution.
Only between a test and the specific code for the behavior under test. It's not good between test suites, abstraction layers, APIs, etc.
> #3: It’s good when something is known to be broken.
When compared to it being broken unknowingly, but not really otherwise.
> #15: The same bug almost never “reoccurs” so most “regression testing” is pure waste.
> #48: Writing tests for bugs that are fixed does NOT correlate with catching new bugs when they arise.
What about a situation where you have untested behavior (perhaps incomplete test coverage to begin with), then you find a problem in that code and write a test to prevent regression. When you later refactor the code under test there's a definite possibility of "regression" of sorts, especially if the refactoring is comprehensive.
> #20: “Black box” is a political designation and has no technical meaning.
A black box is a system where you can observe inputs and outputs but not the system performing the transmutation.
> #31: On a Web site with 1 million visits per week,a one-in-a-million event can occur once a week.
Quoted for thought-fodder, this one is awesome.
> #51: Granular and/or comprehensive documentation of a nontrivial Web site is demonstrably impossible.
It certainly feels this way, but what's the solution? Have no docs, write docs knowing they won't be comprehensive, or expect to chase an impossible goal?
> #66: If no one ever finds out about the bug then the bug never existed in the first place.
wink wink ... this simply isn't true!
> #83: Bugs cluster at the interfaces, bugs are not distributed randomly.
Isn't this only true if there's more unit-level testing than integration/functional testing?
> #84: There’s more time grains in 1 year of compute time than there are seconds in the age of the universe.
1 year of compute time for what? All of the computers in the world? A datacenter? A computer with a 1μ grain size has roughly 3.15E+13 grains per year but there are over 4E+17 seconds in the age of the universe.
> #93: More testing doesn’t correlate with better quality, less testing doesn’t correlate with worse quality.
I don't have any specific data but my experience has been that testing (manual or automated) does correlate with quality. Testing might be the developer pressing F5 a lot, writing automated tests, or a stakeholder manually end-user testing. Think about the state of software which was developed but never run. Software rarely executes flawlessly first-run, and every time a developer runs it, it's testing.
aws.amazon.com (this article link) also loads normally and doesn't appear to contain any indication of a problem with AWS.
My experience has been that support requests can be near zero if you actively work on some kind of automated solution for the highest frequency problems.
It's short for Family Computer.
https://en.wikipedia.org/wiki/Japanese_abbreviated_and_contr...
The article Sophos links with regards to an explanation for choosing PBKDF2 over bcrypt or scrypt goes over numerous obviously bad practices like cleartext storage, then states the following, without further detail:
We’ll recommend PBKDF2 here because it is based on hashing primitives that satisfy many national and international standards.
This seems like a vague and probably misguided line of reasoning. What specifically would make that recommendation rational? bcrypt wasn't new in 2010 when NIST published the article recommending PBKDF2, and they haven't made the switch since. Dual_EC_DRBG was recommended by NIST in 2006 which makes me deeply skeptical of anything they say.
If anyone could provide the motivation for choosing PBKDF2 in reasonably terms I'd appreciate it.
“The issue with these particular devices is that a user cannot feasibly change this password,” Flashpoint’s Zach Wikholm told KrebsOnSecurity. “The password is hardcoded into the firmware, and the tools necessary to disable it are not present.
- https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powe...
That's not to say it couldn't flash the devices but I don't recall seeing that capability in the Mirai source and haven't read about it doing so.
I believe the Dyn attack was via Mirai also.
- putty.exe
- filezilla.exe
- winscp.exe
- mstsc.exe
- mRemoteNG.exe
The malware also has the capabilities to fetch new instructions, so there's no telling what happens when any particular software is detected.
[1] https://securelist.com/blog/research/76147/on-the-strongpity... (linked in the first line of this thread's article)
It's also the 10-year anniversary of Wikileaks.
Failing tests used as a "start here" are to-dos in this instance and are indistinguishable from legitimate currently-implemented feature tests if you've been away long enough.
I don't think it's good to assume it's okay to delete failing tests when returning to a project with new goals or when a bug needs fixing. For me, it's important to return to a project, run tests and have them all come back green. Then if I break something, I know it broke and isn't just an artifact from my pseudo to-dos.
Along those lines... I always try to run tests, check code coverage (including via mutation testing), and commit changes before calling it a day.
For example:
- If you're going to do an API integration in the coming days/weeks, make sure you provide an account with access, documentation, and consider reading the docs yourself to look for blockers. Don't focus too much on the implementation or architecture, focus on the business goals.
- If you're going to make a modification or new addition as the result of a new business requirement, make sure you are intimately familiar with the business domain and how the problem applies. It's important for the PM to understand what the business actually wants, not simply what they say they want.
- Minimize task switching by maintaining a clear strategy with the business side. When you hand off a task to a programmer the task should be in such a prepared state that nothing further can be accomplished without writing code. If business has an "emergency" that isn't, urge them to hold off until the current development task is completed.
- Build relationships. You want to be close to business and close to dev. I would often talk to developers about their day, off-work activities, family events, etc. They were more than happy to discuss their hobbies for a few minutes, I feel like it's time much better spent than group meetings and it gives them reprieve from work. Get to know them, having that connection is great for them when they can openly make requests and likewise for you. Sometimes they need vacation on short notice. Sometimes you have legitimate emergency tasks and need to ask a little extra of them. Having a real relationship to fall back upon is tremendously helpful, just be sure to reciprocate.
As a PM you can advocate for engineers and protect them from waste like excessive meetings and ensure they have everything they need to do their job. You're in a position to suggest raises, hardware upgrades, etc. Sometimes you have to fight for what they need.
You can practice many of these things before being a PM. Some of them are better left for your first opportunity managing a project. Where that line is drawn depends on the specifics of your circumstances. I was promoted to management fast after making recommendations which dramatically increased revenue, which doesn't seem like a bad way to make yourself more visible. Solve business challenges or provide new revenue streams if you're extra ambitious. If you want to manage, show initiative.
It's also worth considering you might not be happy as a PM. No longer coding, it was easy for me to feel like I never got anything done. Entering tasks/todos/bugs, talking with the business side, and writing emails doesn't feel productive after programming. Being ready for that possible eventuality is my best advice.
It does seem like the gap between shutting down and re-launch will hurt their user base, who will invariably seek other services. Many streamers had regular schedules and won't be able to indefinitely wait for the service to return.
And when they return, even with a different format it might address some of their problems but others will remain. Most livestreams suck because most people are not media and/or technology experts. A controversial figure broadcasting? DDOS will still happen. A massive media event using your platform? It could still lack capacity.
From an outside perspective it looks like this decision will be regrettable but it'll be interesting to see how everything plays out.
But are achievements of the 20th century likely to be exclusively the same ones driving the 21st century? These categories are certainly still critical, but is it an exhaustive list?
I don't think anybody denies infrastructure is important. Hillary Clinton's plan is to spend $275bn on infrastructure[1]. Donald Trump wants double that[2]. But if we're going to spend billions or trillions of dollars we might want to make sure it's thoughtfully allocated.
1. https://www.hillaryclinton.com/issues/fixing-americas-infras... 2. http://www.nytimes.com/2016/08/03/us/politics/trump-clinton-...
If program X can write program Y, program X is probably unnecessarily complex with regards to solving problem Y. Program X could simply execute program Y's operations at their abstract level, which would save it all of the outputted language understanding and translation. The only tangible difference between the two would be the ability to "save" the commands, at which point program X is a scripting language and the input commands are the script.
Wouldn't this solution be better in most cases? If program X at runtime requires significant configuration to produce program Y but those configuration inputs are not saved. Then if program Y were to be changed, program X must be rerun with all of the configuration input again. In the scripting language scenario, the script is modified.
For a programming language to receive something simpler than the language it is written in, the ideas must be abstracted to reduce the amount of code required to perform the task. For example simple addition of multiple elements can be reduced to a "sum" function. The "programmer" using this must still have knowledge of the sum function and its use. Abstractions require the system to have knowledge of that domain, so with each new domain a whole other set of abstractions and complications are introduced.
So if a machine were to write the entire program, how does it differ from machine learning? While machine learning might be often used for smaller algorithms, this case would apply ML to the entire problem as sets of smaller problems. If a human must still program in some abstracted sense, isn't it just a scripting/programming language? How would a component of this suggested project not fit into the "machine learning" or "scripting/programming language" categories?
The information is plainly stated in a way which is so simple it's novel.
The payment structure is basically 70% to the seller, or the seller can pay a flat fee of $60/yr to become a "premium" seller and then keep 85% of sales. What's nice about their platform is that the customers are highly qualified and support is mostly offloaded to their support staff. When a customer makes a direct inquiry (to a seller like my wife) about a product there's a very high chance they will actually convert, so time answering questions is well-spent. If a customer wants a refund they contact TPT directly, so it can be a very hands-off kind of thing. We've discussed selling off-site to recover a piece of the 15% but it hardly seems worthwhile because of their infrastructure and how it allows her to focus on creating new products.
TPT has posted engineering job openings on HN in the past and seems like it'd be a great place to work in NYC if anyone is looking. I don't represent or know them personally but get a strong positive impression from their virtual meetings with sellers and people who I know who work closely with them.
As I understand it they have a bit of cross-pollination with the team at Etsy, which is another interesting marketplace similar to TPT but for arts & crafts products. You might know Etsy from their blog at codeascraft.com, presentations they openly host, or because Rasmus Lerdorf (creator of PHP) works there. If not, their blog is worth checking out.
Anything is possible if there's a demand and you market to that audience. Differentiating "cool" from real demand is the hard part. That said, she makes me feel completely inadequate with her side project ;)
Money isn't everything. How sustainable your business is, your required level of commitment on an ongoing basis, and how happy you are doing what you do are also very important.