310 karma · joined May 8, 2012
If you're about to do something 'weird' like fix a merge conflict, you can save the changes by creating a branch.
Sometimes you have to go back and fix a previous commit to reconcile a conflict. The 'gitk --all' command is your friend here. With it it's easy to visualize the history, reset, cherry-pick commits, etc.
Start a project and attempt to maintain a clean history. Break up changes logically into separate commits. To the point where 90%+ don't need more than the subject to describe a change and the history can be read like a story.
Use 'gitk --all' to view the tree of changes. get comfortable with using feature branches, using interactive rebasing to clean up a messy history of changes, etc.
The CLI works great for most things but visual tools make it much easier to write a clean history and reason about the changes over time.
Black box data is retrieved analyzed and scenarios are prepared for pilots to train against.
I used to work in flight simulation and have flown a few different types. I designed the UI for the malfunctions/preselect system and while we had the head pilot trainer in to test the system one day we decided to mess with him.
We gave him a 35kt cross wind. Failed 2 out of 3 of the engines, as well as various hydraulics systems. Aside from the hilarity of watching the simulator engineer following orders to hand-crank the imaginary landing gear, the pilot made a near perfect landing without breaking a sweat.
I've had enough times in sim cockpits to confidently say that I could land a commercial aircraft if necessary. I can also confidently say that it would take me a dozen attempts to make that landing without crashing. Let alone a clean almost textbook touch down.
Tracking profile progress via GitHub issues wasn't feasible so we were working on a site where users could login with their GH account, choose a curriculum track, and manage their progress.
Between the 2 teams there were about a dozen very active contributors. Things were marching quickly toward a MVP. One contributor even purchased a domain name for the site.
Eric came kind of late to the party to the actual development. We had already elected team leads and used a consensus model for decision making. Eric either didn't understand or didn't approve of the direction some things were going.
He probably meant well but he was leaning very heavily on the 'my way or the highway' approach to coercing the devs. At one point I stood up for the decisions the teams had already come to a consensus on and was threatened with being kicked from the project as a result. I left soon after when he started screwing around with write access permissions to the project repositories.
One of the other core contributors reached out to me directly a few weeks later. From what I heard, Eric decided to ditch the existing development effort in favor of building a static generated HTML site. As a result, all of the active devs left.
That's pretty much the exact point in time when his contributions stopped.
Aside: I don't know if this has anything to do with it but he was trying to get me or one of the other devs in the US to create a non-profit organization (ie 501c) for the project.
Breaking changes to the language syntax/semantics.
I'd expect breaking changes to apply to core APIs and/or to external tooling as both could probably use some revision now that the fundamental issues with the language (ex utf8 support) are mostly fixed.
His blog was by far my favorite. It touched on topics at a much deeper than anybody else and it's clear that he looks at the world from a brutally practical and realistic perspective. Something that's sesperately needed in an industry dominated by math/CS purists and architecture astronauts.
I hope, one day he leaves the Borg and continues to contribute meaningful commentary.
This isn't a criticism. Raher there are aready some well established FRP libs in JS. What's unique about this offering that would make users want to adopt it?
The point is, walk/filter the data completely prior to updating the view.
Immutable sets may also 'seem' inefficient but compare-by-reference works a of a lot faster than change propogation with compare-by-deeply-nested-values.
In CompSci terms, multiple passes are still O(n) and the data sets aren't large enough for micro-optimizations to matter. Compared to O(holy shit) of triggering many cascading DOM updates, it's a huge improvement.
'Seems' isn't a good enough metric to justify optimization.
Preventing a user from sending bad data to begin with avoids the poor usability of having to send bad a failed request and reset the form for editing.
Database constraints only avoid bad data in the database. They still have to be duplicated for error checking in the server and client.
Is JS is used on both the server and client, it makes a lot more sense to have ORM models that act as the single source of truth for structure (ie model/schema), condtraints, testing, and validations.
Issues with unstructured data come either from laziness (ie not using schemas in production code) or mismanagement (ie not handling migrations properly between schema changes).
Having the ability to use completely schema-free, unstructured data doesn't mean schema/validations should be ignored altogether.
You wouldn't blame the gun if you shot yourself in the foot, would you?
What if I want to distribute a package to an audience that doesn't have a strong Python background.
What would otherwise be a simple 'pip install' just turned into a complex multi-step process to install a new version, update PATH, and use virtualenv to avoid conflicts with the default install used internally by the OS.
These all seem like 'simple' fixes to a regular Python user but they set a huge barrier-of-entry for others.
'Just use [insert python specific fix]' is a UX failure for a language that emphasizes usability.
To reiterate. Python3 is ready for regular python users/devs. Not so much for the rest who consume python applications.
Per-project configurations to map things like external dependencies and project info. Setup.py + MANIFEST is not the answer.
Better suport of versioned deps so multiple versions of the same dep 'just works' when its neessary.
Better package publishing for library maintainers. Have you ever published a pckage to PYPI? It's a huge pain.
Support for Markdown-based documentation on PYPI. ReStructuredText is cool and all but MD os the defacto standard
Standard support for direct install from GitHub without weird hacks.
Pick one unified standard and deprecate the rest. The current 3, distutils, distutils2 and setup.py all suck.
Write some halfway decent docs on how to publish packages. I spend more time on Stack Overflow that the python docs every time I publish a package.
Dependencies are used so heavily in the JS/Ruby ecosystem because it's extremely easy to publish a package and the package manager 'just works'.
Seriously. Where are all these companies that foster a healthy remote work environment?
Every time I check it as baggage, I get it back with a TSA certificate notifying that it was searched.
Of course, I'm probably on some list now as a result. So, I got that goin' for me, which is nice.
The speaker mentioned that it has a lot of great content if you ignore the shockingly bad predictions about the future of advertising on the web.
I'll definitely add them to my reading list.
What python really needs in 4 is better unified package management and distribution support. They have a lot to learn from the Javascript and Ruby evosystems.
Ubuntu is actively working on the transition but the current LTS release (ie the one companies/enterprise will use) is still locked onto python2.
The same can likely be said for other flavors of *nix.
From a user's perspective, python3 has been ready for 'prime time' for a while. From an OS, systems, enterprise perspective python3 still is still a ways out.
SQL can be even more of a pain because you'll need additional checks to handle the SQL server's particular blend of error handling if/when something goes wrong.
In both SQL and NoSQL, any decent ORM should provide models, validations, sane error handling, and constraint checks so none of those really matter.
Unless, for whatever reason the business logic is defined in SQL SPROCS. Then, good luck if/when they don't work properly.
SPAs are (relatively) slow to load. To improve perceived performance, the view requested is prerendered on the server with the ability to capture user input. The user sees a fully functioning site while the app bootstraps in the background.
Once the app is finished bootstrapping, the user inputs are replayed on the actual app.
This fixes the problem of poor perceived initial load times that come with SPAs. Once the app is bootstrapped everything is fast/snappy as one would expect with a SPA, incl no page refreshing between URIs.
Isomorphic React is already supported. Isomorphic Angular2 (ie Angular Universal) is in the works. I don't know about Ember but I'd assume they already support it.
Maybe that's indicative of the new 'data platform' development team they're actively recruiting for.
I'd post a link but it was originally hosted on blip.tv and no longer exists online.
It's by-far the most influental talk about marketing I've come across covering the 'New Coke' branding kerfuffle as well as a lot of other great examples (ex Southern Bell's rebrand to AT&T).
The message, a brand is essentially an immutable const identifier in the minds of the users. Once people establish a firm perception about a brand, it sticks for life. Diluting a well established brand by turning it into an 'umbrella brand' does nothing but erode its value and confuse the users. Once the damage is done, it can't be undone.
By controling the platform, Google can leverage the ecosystem to attract and cherry-pick early adopters to the language.
Once the language becomes populat enough that the Enterprise starts to adopt it, Google will already be onto their next 'ground breaking' technology.
Once people settle on a perception they tend to hold on to it for life. One day soon people won't want to use Java. It'll be seen as "our Dad's language". Steve Yegge (ie now a Googler) said as much during his OSCON 2007 talk.
The value isn't in the language/platform, it's the people who adopt/build/use it.
Microsoft knows this, developers are what kept them afloat during a decade of stagnation in product development. Oracle thought they could buy their way in by acquiring Sun; except, while they were busy suing Google, Amazon sprinted ahead of the pack with their cloud services platform.
This is how the biggest players make long-term investments. Guarantee an abundant stream of top tier talent and success will follow.
Forcing everybody into a single, homogeneous culture dictated by a central authority is a recipe for disaster.
People often point to the chaos that takes place in the US government as a 'failure of Democracy'. I'd argue the opposite, it's a side effect of a successful Democracy that supports a wide variety of subcultures with different beliefs/norms.
It should be extremely difficult to establish a universal consensus.
The danger comes when the central authority makes declarative judgements that affect everybody without working out foing due diligence. Some topics can't be addressed globally and therefore should be defined locally or not at all.
Universal laws work best when they're used to guarantee basic human rights and freedoms. Unfortunately, some groups try to manipulate public opinion and garner support by attaching 'human right' to whatever particular pet cause they're trying to force.
I find it very difficult to see astrophysics as a field of science. .1% involves creating models that describe gravity, movements of the planets, etc. Whereas the other 99.9% is selling bullshit narratives to society on the vastness and all-knowing/all-seeing grandeur of the giant vacuum surrounding our little planet.
Instead of being intellectually honest and admitting that the proofs/measurements required to verify their findings either aren't possible with current technology or aren't possible at all; they use the lack of reason in religion as some sort of pseudo contra proof.
The truth is, we know very little and we're collectively too terrified by that fact to admit it.
It'll give you a clear measurement of a candidates ability to do CS homework and not much else.
People are overly concerned with being 'correct' all the time. Sometimes I'll talk out of my ass and pick a side on a topic I know little about because usually thr person who knows more will either confirm or correct my assumptions.
It's a surprisingly useful tool to learn in-depth knowledge from others on just about any topic. You just have to be careful not to over use it as blind skepticism has a tendency to piss people off.
This just gave me a flash back to back when I used to play Starseige Tribes.
The chat system included quick key commands for a ton of useful voice callouts.
The quick keys and audio sampling made them a lot more fun to use and harder to miss than manually typed messages. As a result, it was much less common to see typed messages popup during regular gameplay.
Looks like they still use the chat system in the latest iteration of the series. http://www.tribesascendwiki.com/Voice_Game_System
I use ctrl-left and ctrl-right to switch virtual desktops. Can't remember if that's the default or if I used custom keybinding. There are a bunch of other window management keybindings that can be found in the OSX System Preferences.