Just for the sake of clarity, the article recommends bacon as a "source of healthy fat" (not a "healthy source of fat"), where they specifically define "healthy fat".
In all seriousness, if this is what you encounter at your workplace, you need to get out and work somewhere else; this is an extremely toxic environment.
Even if the build setup is the most complex thing on the face of the earth, if you or team members get reported for undermining the team because you don't understand it, then those are not the team members or managers you want to work with or for.
Having gone through the process of marrying react and d3 - IMHO it's far easier to let react do DOM diffing and manipulation, and let d3 worry about data processing. The two work great together, just so long as you don't try to shoehorn one into the other. React more or less mirrors data(), enter(), and exit() with props, componentDid(/Will)Mount, and componentWillUnmount
Having officiated the same kind of union between Ember and D3 in a few different ways, I have to agree - let Ember handle rendering, and D3 handles dynamic data binding. I've been working on an open source Ember library based on these concepts:
http://locusenergy.github.io/ember-sparkles/#/sine-wave
Yeah, that does exactly the thing I was describing from a quick skim. https://github.com/uber/react-vis does it as well. I've found that attempting to wrangle one of these chart libs takes more time than a quick `myData.map(d => <line path={linefunc(d)}/>)` or similar.
There's probably a couple reasons, but I'll summarize my experiences with them.
I haven't dug into MySQL for a few years (last I really worked with it was 5.5), but out of the box, it does a lot of things that are pretty unsafe or encourage bad practices, such as truncating data when it's longer than the column size, inserting the zero-value for a NOT NULL column rather than erroring when a NULL is inserted, confusing timestamp column behavior, no DDL-level transactionality, etc. Additionally, and not necessarily a bad thing, but it has made some odd implementation and feature decisions that can be (IMHO) counter-intuitive or have a large impact, particularly with regards to how foreign keys get implemented, but also with things like not having schemas (database > tables, rather than database > schemas > tables), not having a boolean type, its datatype specification (int(1) means an integer that displays only a single digit, rather than denoting storage sizes), or the fact that every ALTER TABLE causes a complete on-disk table rewrite.
PostgreSQL, on the other hand, makes every attempt to keep 100% data integrity at all times, has a lot of killer features (probably the best date/time math implementation I've ever used, typesafe operators, etc), is generally very extensible, and most importantly, is extremely predictable. True, it doesn't have the same scalability features out of the box that MySQL does, but that's getting better every release, and as mentioned elsewhere, there's plenty of adequate third-party tooling available (e.g. Slony).
I think MySQL is very much so the PHP of the RDBMS world - it does a lot of silly stupid stuff - mostly for historical reasons - but in the hands of someone who knows how to use it properly, it can be an extremely useful tool. Postgres just defaults to being an extremely useful tool out of the box without needing to know all the gotchas that come with it.
> I haven't dug into MySQL for a few years (last I really worked with it was 5.5), but out of the box, it does a lot of things that are pretty unsafe or encourage bad practices, such as truncating data when it's longer than the column size, inserting the zero-value for a NOT NULL column rather than erroring when a NULL is inserted, [..]
Sure, I'll throw my hat in the ring here with a shameless self-plug.
I help maintain a database versioning/migration tool that my team has been successfully using for years now: https://github.com/nkiraly/DBSteward
The idea is that instead of managing a schema + several migrations, you just store the current schema in XML, then generate a single migration script between any two versions of the database (or just build the whole thing from scratch). The ideal use-case during deployment is to checkout the existing deployed schema into a different directory, then diff against the current and apply the upgrade script.
I've always found most migration solutions to be wanting, and while this approach has its downsides (things like renames can be hairy, need to explicitly build in support for RDBMS features), I do like it a lot more than the standard sum-of-changes approach.
The tool is still very much a work in progress, written in terrible 10-year-old PHP, and desperately in need of a proper rewrite and modernization, but it is definitely stable, safe, and production ready.
I'm surprised that no one's pointed this out yet, but isn't this basically the same as Knockout (http://knockoutjs.com/)?
The difference being that Knockout's been around forever (first release was in 2010), does two things and does them well (data binding and observables), and is very mature and feature-complete at this point.
I don't have any comparison performance-wise, but I don't see anything new and exciting feature-wise in JSBlocks that Knockout doesn't already do.
It is similar to Knockout. However, Knockout is hard to manage because you have to invent architecture on your own while jsblocks offers MVC out of the box. Additionally, Knockout don't have routing, server-side rendering, animations, filtering, sorting, paging, lazy loading of views, validation, working with remote data out of the box.
I just looked, and unless you're talking about something different, Sublime Text 3 allows disabling telemetry by way of the "enable_telemetry" setting.
As someone brand new to Ansible, and having been developing on OSX for years now, I'd just like to play devil's advocate.
Finding the Ansible docs (http://docs.ansible.com/) was not as easy as it could be, however, the install instructions were easily accessible from there, exactly where I'd expect them: Introduction > Installation > Latest Releases via Homebrew.
Second, yeah, pip sucks, I try to avoid it at all costs. However, homebrew (http://brew.sh/) is that one thing that all OSX power users should install as soon as they touch their workstation. 90% of the software - CLI or GUI - on my MacBook is installed and managed by homebrew. I cannot recommend it highly enough. In fact, I didn't even install Ansible through their instructions. I read about it somewhere else, and thought, "Hmmm, I wonder if this is in homebrew? `brew search ansible` Oh! Sweet! `brew install ansible`" Worked perfectly the first time, and I haven't fiddled with it since.
Oh man, that's awesome! I see I'm not the only one with an addiction to d3 and knockout. I've actually just recently gotten around to playing with the two of them at once: http://jsbijn.com/gitufejo/3/edit?html,js,output
Not to be completely contrary - in fact, I much prefer SVG + D3 to canvas - but the canvas actually can support quite complex interaction and be performant if you put the time into it.
Granted, these absolutely crush Firefox (Chrome handles them fantastically; IE about average), but they're still great examples to how performant the canvas can be. As far as interactivity goes, all you need are a little bit of extra attention to your events and rendering, and it works just as well, if not better, than SVG in many cases. Look at http://ol3js.org/en/master/examples/draw-and-modify-features... for a good example.
Of course, OL3 is both highly specialized to mapping applications (you know, being mapping library and all), and highly optimized for canvas rendering, but it does serve to show flexible canvas can be.
