Could you share more about how you've used it for less structured information? I've used Anki for about 3,000 Chinese words, and also some structured information (world capitals / countries). I've been experimenting with Anki for more conceptual knowledge and it's not nearly as easy.
Probably the CS stackexchange (http://cs.stackexchange.com/), or CStheory (http://cs.stackexchange.com/). Unfortunately, neither are anywhere near as popular as StackOverflow, so the chances of getting a good discussion are lower.
I think the main point here is to avoid general catches and instead catch specific exceptions.
The author raises the interesting point that if it's truly an exception, you're better off letting the system crash all together (especially in a webapp, where you're basically dropping a single request for a single user) -- and if it's an "expected exception", then you should be handling it directly.
I don't see how that reduces to "never use try/catch" though, since catching a specific exception (or types of exceptions) is a way of "handling it directly."
Unfortunately, "Don't do X" is better click bait than "You should think carefully when you want to do X".
There will be cases where you want to do "catch {}" — you don't always have control over the exceptions thrown by a lower-level library. It might be good to create a standard where you log them conditionally, or something that could aid in troubleshooting.
Oddly, I have seldom seen an empty catch {} without a comment, though often it was simply to point out that, yes, this is intentional. Even that is better than leaving me wondering if the code is just unfinished.
Yes, in my front controller I wanted to log to the filesystem & email exceptions. The email library threw it's own exceptions, which I wanted to ignore with "catch {}"... if email was down, and I already logged the exception, there's nothing left to do.
Not only are the points you raise valid, but I feel the webapp example exemplifies the strengths of exceptions: That the default behavior is to propagate to a context that can deal with the exception, and that you can catch them all at strategic points, like the main request handler of a webserver. You're not "crashing the thread" like the article implies: you're purposefully catching some error you didn't expect (bugs happen), logging/capturing it for debugging (perhaps even with a traceback), and gracefully returning at worst a 500 to the current request, all the while continuing to serve further requests.
It's been best practice for quite some time not to catch { // heh heh he. }.
Something about this just strikes me as arrogant. Please enlighten me if I misunderstood ...
"How does it work?
We communicate with Snapchat's servers and pretend to be their mobile app. This gives us access to everything that you can do through the mobile app. For example, we can send messages, view (and save) messages, create new accounts..."
That's a detail that's not relevant at all to their "users" (the people sending in snapchats). It sounds like they're bragging about their circumvention of Snapchat's lack of an API.
I don't want to diminish the technical accomplishment here -- reverse an engineering an API and writing a Snapchat bot is impressive. But, as other posters have pointed out, they're likely violating the Snapchat terms and misleading their "users."
Is it impressive? Unless Snapchat put a lot of work into making the binaries prevent RE (which, in ios is probably unlikely due to runtime restrictions), it's probably fairly straightforward.
On another note, the only way an app dev could really prevent this is if mobile devices had some sort of TPM or other remote attestation feature.
The says that a big barrier to adopting 'open source science' is the prestige that comes with publishing in heavy weight, closed journals. It then draws the comparison to software, and why open source software is quite successful:
> Addressing this issue, Toni references the open spirit amongst coders working on open-source software. “There’s no reward system right now for open science. Scientists’ careers don’t benefit from it. But in software, everyone wants to see your GitHub account.”
This got me thinking. First, I think a large reason a lot of people (read: people in my bubble, mostly students / recent CS grads) use GitHub is precisely because of the prestige. I'd say the people who use GitHub without ever contributing to an open repo vastly outnumbers the people who do contribute. Instead, many people start using GitHub as a way to show-off their own projects -- the whole "GitHub as my resume" idea. But as more people do so, having a GitHub becomes a standard, and you get a positive feedback loop.
Second, how could we shift the status quo for science to associating prestige in an open system? I'm not familiar with the history of open source software, but I wonder if there are any parallels from how OSS grew that we could apply to science publishing.
Finally, there's a big systemic difference between doing collaborative science and writing open source software I can think of:
the barrier to entry to software is much lower. A lot of hobbyist programmers contribute to open source projects (or at least have a GitHub account, which feeds more attention / prestige to the ecosystem), whereas it's pretty hard to contribute to science without both a graduate education and (in many fields) expensive equipment.
> how could we shift the status quo for science to associating prestige in an open system
If you're sufficiently motivated to consider actual engagement, you might like to think about lending support to the excellent work being done by the Open Knowledge Foundation (http://okfn.org)
"The Open Knowledge Foundation (OKF) is a non-profit organisation founded in 2004 and dedicated to promoting open data and open content in all their forms – including government data, publicly funded research and public domain cultural content."
There's plenty of opportunity to get in there and make a significant contribution, e.g. http://openbiblio.net/ just to pick an example at random.
Semi related question -- how is this implemented security wise? I took a look at the github repo and it seems to be all clientside JS, and it's just making ajax GET search requests to StackOverflow, then parsing the results. Isn't this prevented by same origin policy?
The problem with this is that it can take a significant amount of the candidate's time. Scheduling a project (here's a spec, you have 3 days) is a major inconvenience for a lot of candidates.
I haven't used an iOS device since I switched to the Galaxy Nexus about 5 months ago. How does this compare to Google Now on android 4.1?
In general I've been very pleased with voice search on Google Now -- just reading the blog post I wasn't too amazed by the examples they gave for iOS because it sounds identical to what Google Now provides. I assumed that Google would release these features for android before iOS, but am am surprised by the overwhelmingly positive comments others here have to say here. Can anyone do a comparison and shed some light?
I do have to say that Google Now is sometimes rather slow -- the voice recognition is very fast (type as you talk realtime) but web search can sometimes take 10+ seconds to load even when already connected to wifi. Other times, it just works.
If you're switching from an iPhone, and can make do with 16GB of space, buy the Nexus 4 once the reviews come in (unless the reviews show something startlingly wrong). The nexus phones are where you get the iPhone equivalent experience of fast, long term updates and no carrier BS. (Except the Verizon Galaxy Nexus, which is why Verizon isn't getting the Nexus 4).
Alternatively, if the 16GB isn't enough, or you must go Verizon your choices are either the HTC One X or Samsung Galaxy S3. Read the reviews see which suits you better.
There are a horde of cheaper phones. And yes its confusing the choice in the mid to low end. But if you're switching from an iPhone, those aren't aimed at the same market. You can get one of them, but unless you're still using a 3GS it will be an inferior experience.
I'm not sure having a modal is the best idea -- aren't modals generally frowned upon because they require a mental recontextualization and disrupt the user's flow? I'm just curious if anyone else had this thought.
Although I can see why having a prepackaged one-button solution would make sense, where Stripe takes care of the presentation / styling / inputs, so there actually is a change of context.
For the record, I use Stripe at my company, and I love it!
