I’m not a fb apologist by any means, but maybe we should stop blaming these websites for everything and invest in education instead.
275 karma · joined March 30, 2015
I’m not a fb apologist by any means, but maybe we should stop blaming these websites for everything and invest in education instead.
I feel as though this crowd gets wrapped around the axel on these kinds of questions - anything with too much ambiguity that can't be code golfed into the tersest possible formal logic statement.
When Justice Stewart attempted to define what "hardcore pornography" actual __is__ he simply wrote "I know it when I see it" (1964 Jacobellis v. Ohio).
That's about as good as one can do in some cases.
Firstly, valuable data tends to live in places accessible via web technology. Maybe you need to fetch a bunch of XML files from an FTP site? Having a clear understanding of all the nuances you're about to encounter will set you up for success.
Secondly, valuable data tends to be generated by web technology itself. Understanding that lifecycle can inform analytical strategy.
Finally, some data scientists add value by informing decision makers. One of the most powerful things you can do for them is give them a mobile friendly secure web experience that puts the data they need directly at their finger tips. While yes, Tableau et al. are an option here, you'll be ahead of your peers by knowing how to DIY it when it counts.
We want houses before we can save enough money to afford them. We want applications before we know how many users will be slamming our servers. The common denominator here is time. We're trading in time - the only question to ask is whether it's being done for the right reason.
The wrong reasoning is usually something like "it would take too long to understand how to do it better".
When a better solution is understood to have obvious merit but nebulous short term applicability - that's probably good technical debt to take on.
[1] https://en.wikipedia.org/wiki/Juno_(company)
Edit: Typo
Example $2333 build: https://pcpartpicker.com/list/t4FjZZ
Could a hypothetical FarmPod3000™ exist at a reasonable scale? I mean, people built greenhouses before right? Could such a system be economically viable at the size of a shipping container? A family home? Staten Island?
To be clear, I don't think the FarmPod3000™ would disrupt 90M acres of corn farms - we actually eat <10% of that anyways[1].
We should factor in the +/- environmental & public health impacts of such a system to the viability calculation as well.
[1] https://www.washingtonpost.com/news/wonk/wp/2015/07/14/how-c...
1. If you don't have users, you don't have technical debt (you might have lot's of #2 though). You could frag the entire app and the only thing of value (not potential value) lost would be your job. Debt implies value was quickly received in exchange for a flexible re-payment schedule (of time in this case, not money); if the code is not actively being used to save/spend/gain some resource then that value exchange has not happened yet.
2. Correct Code* that is unclean and could be improved in <= time that it took to write is just bad code. Fix this code now.
3. Correct Code that is unclean and would take significantly more time to improve than it took to write is technical debt (but only if you have users). This is where a balance needs to be struck between business needs and development needs. Manage this code carefully.
*code that correctly implements business logic, incorrect code is always bad - no matter how long it took to write.
Sure, AI has its faults; the tantalizing cost savings of automation has created some negative feedback loops - might that be more deserving of the question "what in the hell are we trying to accomplish and how exactly did we get here in the first place?"
A Rubic's cube solver is the problem? Really?
OpenAI (of now infamous Rubic's cube failure :p) released a hide-and-seek demo a few months back that gave me literal goosebumps. Little AI agents facing off in a game of hide and seek start evolving with seriously clever strategies. According to the author's bio (dynamic, time-aware ML systems, etc.) that sort of thing should be right up their ally!
Instead we get some sort of selective self-promotion hit piece - highlighting anecdotal failures while claiming some better AI based robotics startup is coming soon(tm).
"i've been asked to use Json to call a webservice. I don't modify a JSON object at all. However, when calling JSON returned by the Json object, it fails because the object life isn't array!"
"... another aspect that needs to be studied is whether its extremely low density could be maintained while in the parent system, during its long interstellar journey, and when entering the solar system."
Without analyzing the structural integrity of such a fluff ball it's tough to give any more or less merit to this concept than the others.
5 Paragraphs later:
It would be the same price as the sector-leading Maruti Suzuki, but with more space. It would include a 7” infotainment system with a touchscreen. It would have real ground clearance. It would resemble a smaller version of Renault’s wildly popular Duster SUV.
New sexy features don't make something disruptive. Sure, it may pan out to be a popular vehicle, but disruptive? because it has infotainment?... spare us.
There was a great episode of Radiolab recently called "The Rhino Hunter" that accomplished this wonderfully.
It's still early, but that seems to be the direction this season is going. At the very least, those on either side will be more informed.
When I left grad school I found many of it's problems present in the corporate world; except that now, compensation is commiserate with responsibility.
My stubbornness is rooted in the simplicity of print. It is so simple and stupid, why change it? Never has a production app relied heavily on print, it's just a dumb way to check shit while developing. I mean sweet jesus if it ain't broke right? I know I'm wrong in thinking this kind of thing happened everywhere in the 2->3 increment, but as I said earlier, I'm under no illusion of rationality. Python 3 broke hello world, and that just skeeves me out.
Eventually I'll write new stuff in 3, probably sooner rather than later especially with asyncio et all, but for now I'll stick with 2.
for script in soup_obj(["script", "style"]):
script.extract() # Only need these two elements from the BS4 object
That comment is a bit misleading. soup.extract() will remove those tags from the tree, 'script' and 'style' are the two tags you __don't__ need.http://www.crummy.com/software/BeautifulSoup/bs4/doc/#extrac...