HNHacker News
TopNewBestAskShowJobs

jmakeig

48 karma · joined November 20, 2011

Enterprise software Product Manager, web and data nerd based in the San Francisco Bay Area.
submissionscomments
jmakeig··on Functional, stateless JavaScript finite state machines and statecharts
This took me a while to figure out, but it’s incredibly powerful once you get it. As others have suggested, I was working on a Redux-based interpreter.
jmakeig··on Introspected REST: An Alternative to REST and GraphQL
REST allows for clients and servers to evolve independently. If you can constrain that you can probably design something significantly simpler. That’s not a shortcoming of REST, though. The channel between your mobile client and your backend would probably be better served with something more like RPC than academic REST.
jmakeig··on Living APIs and the Case for GraphQL
HATEOAS is designed so clients and servers can evolve independently, like on the open web. If you control both ends, HATEOAS is probably overkill. (And that’s ok.)
jmakeig··on MongoDB gets support for multi-document ACID transactions
The problem isn’t the schema, it’s that you must have exactly one at all times. Sometimes you need zero, sometimes you need many. Having a fixed schema in production reduces unpredictability and provides optimization opportunities. The journey to get to that fixed schema, however, generally benefits from more flexibility.
jmakeig··on MongoDB shares jump more than 30% in $192M IPO
Only? Many of the early MongoDB employees came from MarkLogic. Several have returned too.

(Full disclosure: PM at MarkLogic)

jmakeig··on REST in Peace. Long Live GraphQL
Or your data is…you know…mark-up. Imagine a biology textbook, or legal contract, with inline citations and entities. There’s lots of marked-up human text around, even if that’s not what you’re sending to a JavaScript front-end. (Ironically, all of our JavaScript front-end frameworks are ultimately building mark-up as documents for human consumption.)
jmakeig··on REST in Peace. Long Live GraphQL
If you control both the client and the server, there are lots of shortcuts you can take. As you say, that’s not the problem that REST was trying to solve, though.
jmakeig··on [dead]
That is clearly an invitation to Netflix and chill.
jmakeig··on ‘I’m Here to Help,’ U.S. President-Elect Tells Tech Executives
This was nothing but a ring-kissing ceremony only to boost Trump’s own ego. The entire Trump campaign has been a sophomoric revenge fantasy exacted against the (actual) elites who have excluded him his entire life. Trump is not interested in solving problems—that’s hard work without clear benefit to himself. This meeting was a public airing of the fact that he “won” and now those with real economic or social power need to kowtow to him. Having his children there only reinforces this. It would have been refreshing for someone—anyone—to object to Don, Eric, and Ivanka being present.
jmakeig··on RethinkDB needs a new home
Argh! They didn’t charge for the component of their offering that was most valuable. Period. Good software doesn’t pay for itself. Consulting and training are difficult to scale, mostly because they require adding people. As such, the margins are minuscule compared to software. “Free” gets you downloads and publicity, but it doesn’t pay the bills. I really liked Rethink’s story and how well they executed things like branding and developer outreach, but without being able to capture the value of what they were producing it’s hard to see how that’s sustainable.
jmakeig··on Safer branching
This is a cultural problem not a technical one. The social contract in a dev team should strictly enforce no cowboy commits to master…ever. If Bob thinks that’s OK, there are more issues than a UI warning is going to solve.
jmakeig··on React Router v4 FAQ
I'd love some backstory on this too. I (kind of) understand JSX for HTML, but declaring routing rules seems very far from that.
jmakeig··on Horizon 1.0: a realtime, open-source JavaScript back end from RethinkDB
This looks really cool, but I still don’t understand how Rethink plans to cash out their VCs, though—~$12M, according to Angel List. Cloud hosting is trending toward zero and support/consulting only scales with people. I’m not to trying to be (intentionally) critical; I’m genuinely curious and hoping there is some business model innovation going on here too.
jmakeig··on Two Weird Tricks with Redux
I created a quick code generator[1] for async action scaffolding just for this reason.

[1] https://github.com/jmakeig/redux-thunk-scaffolding/blob/mast...

jmakeig··on What MongoDB got right
ACID transactions in a highly available distributed system are hard and often fail in subtle ways when done wrong at the edges. Any implementation will take years to mature in the lab and in actual production usage. This isn’t a knock on the Rethink guys; their product looks pretty awesome and is moving quickly.

For a solution today, MarkLogic is a transactional distributed document database. Cross-document and cross-partition transactions have been a key tenet of the architecture from the beginning (like, 2002 beginning). Take a look at https://developer.marklogic.com/blog/how-marklogic-supports-... for details.

Full disclosure: I’m a Product Manager at MarkLogic.

jmakeig··on RethinkDB 2.2: atomic changefeeds, parallel scans, improved runtime
And it’s a database with indexes and caches.
jmakeig··on The Effects of Uber's Surge Pricing: A Case Study [pdf]
OK, I'll bite: What is "fair"? Isn't allocated to the users who value it most fair?
jmakeig··on The Effects of Uber's Surge Pricing: A Case Study [pdf]
Maybe "efficient" would have been a better word than "good". I have no doubt that Uber is pricing to benefit their shareholders, not the public good. That's why the taxi fare regulations are there in the first place.
jmakeig··on The Effects of Uber's Surge Pricing: A Case Study [pdf]
"Couldn't afford" is a loaded term. I can afford a helicopter ride home, but I don't value its utility enough to pay what's being asked. Isn't that how prices are supposed to work?
jmakeig··on The Effects of Uber's Surge Pricing: A Case Study [pdf]
Great read and thorough approach. However, it's worth noting that Uber provided the data for this study. I'd imagine they had an idea as to its conclusions before they provided it.

The findings are intuitive and validate that surge pricing is an overall good thing for the market.(Yea, microeconomics!) However, the cynic in me isn't sure we'd have seen a study that didn't come to that (positive) conclusion.

How does an agreement between an academic and a data provider work to prevent this sort of bias? (In the general case. I have no evidence of that in play here.)

Update: speling

jmakeig··on Meteor Raises $20M to Build the One JavaScript Stack to Rule Them All
http://developer.marklogic.com/features/javascript

(Full disclosure: I work at MarkLogic)

jmakeig··on Elasticsearch: dealing with complex permissions
[Full disclosure: I’m a product manager at MarkLogic.]

MarkLogic can handle all of these requirements with aplomb. You can think of MarkLogic as a database built with search engine technology. It uses a document data model (text documents in XML or JSON). Each term (word, phrase, parent-child relationship, etc.) is indexed on ingest. There are index knobs and levers for things like diacritics, wildcards, and scalars, like you'd expect in real search engine.

As for document permissions, they're indexed just like other terms. However, they’re automatically ANDed on to each query in the database engine, not application code. MarkLogic supports role-based permissions (read, write, and execute for stored procedures) with optional Kerberos and/or LDAP auth*n.“Ignored/hidden items” are those that a user doesn’t have permissions to access.

"Followed/watched items" is a pretty common requirement. MarkLogic uses a special "reverse index" to index queries along with text, values, and structures. With regular "forward" queries, queries find documents. With reverse queries, documents find queries. Thus anything that can be expressed in a query can be turned into an alert. This provides some pretty powerful match-making where a document can express its own attributes as well as those it’s interested in matching. Hook that up to a trigger (pre- or post-commit) and you have alerting that scales to billions of documents and millions of queries. One of the world’s biggest news sites uses this infrastructure on a MarkLogic cluster to handle saved searches and alerts.

jmakeig··on ArangoDB 2.3: Overhauled query optimizer, AQL improvements, new Foxx features
Looks like a FLWOR statement in XQuery.
jmakeig··on Building an earthquake map with RethinkDB and GeoJSON
Yes, MarkLogic includes a full HTTP client and server so you can create and consume web services. In XQuery this would look like:

  xdmp:http-get("http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/2.5_month.geojson")
or in the upcoming release, you'll be able to do the same in server-side JavaScript (embedded V8):

  xdmp.httpGet("http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/2.5_month.geojson");
(Full disclosure: I’m a Product Manager at MarkLogic.)

I find this really convenient for quickly standing up web services and doing ETL-type logic that runs close to the data in the database.

jmakeig··on When REST Gets Messy
REST, as Fielding described it, is good for decoupled systems that can (and need to) evolve independently, like web browsers consuming HTML and JavaScript.

If you can relax the decoupling or independent evolution constraints, RPC over HTTP is usually easier to understand and implement. This is where most HTTP APIs fall. (…and that’s OK)

jmakeig··on Bash [ -z hello ]
http://explainshell.com is what you're looking for.
jmakeig··on JSONPath - XPath for JSON
Parsing and accessing are two different tasks. Even if you have an entire JSON (or XML) data structure in memory, getting to the right pieces can be difficult. “Return all of the order entries contained in an a shipment of type ‘Billable‘ whose total price is less than $500.” In the JSON world you’d typically write some imperative code to loop through the data. XPath allows you describe things like this without having to get into the nitty gritty of how the traversal is actually performed, similar to how CSS selectors work with the browser DOM.

I do look forward to the JSON community (re?)developing schema and transformation languages to go along with this.