Also: https://hn.algolia.com/?query=http:%2F%2Fkparc.com%2Fq4%2Fre...
753 karma · joined May 28, 2014
Also: https://hn.algolia.com/?query=http:%2F%2Fkparc.com%2Fq4%2Fre...
- https://github.com/johnearnest/ok
There is also a more recent example of Arthur Whitney writing a C compiler in <250 lines of C. Remarkable how productive a programmer can be when he chooses not to overcomplicate.
1. Identify problem.
2. Market size?
3. Solution differentiation?
4. Price?
5. Profitability?
6. Execute: productize, place, promote.
Principles of Effectuation:
- Start with your means - possibilities originate from my means
- Focus on the downside risk - what can I afford to lose at each step?
- Leverage contingencies - surprises/"bad" news are clues to new markets (pivot)
- Form partnerships - early pre-commitments from stakeholders for venture co-creation
- Control vs. predict - focus on activities in my control, not predictions
Effectuation process for building new products, markets, and firms:
1. Means: who am I, what I know, whom I know
2. Goals: what can I do?
- Pursue goals within affordable loss
- Leverage surprises - may add to Means and change Goals
3. Interactions: interact with people, enlist co-creation to change original idea
4. Commitments: gather stakeholder/customer commitments to co-created/morphed idea
- New means - new resources add to Means
- New goals - new commitments help crystallize the Goals
Edit: And just in case it wasn't obvious, I prefer to maintain my todo list/logs/notes/projects/bookmarks in a single plaintext file. Grows about 30k lines/year. Vim search/grep and some basic structuring/naming conventions go a long way.
Top of the file is my todo list with priority order of top 3 tasks. Next is a 'Waiting For' list. Last is a 'Projects' list for longer term, high-level categories. This fits on a single screen. Completed tasks, meeting notes, logs, bookmarks, etc., go below in chronological order and are all associated with a date. This system has worked well for the last decade or so with minor changes.
[1] https://github.com/srpeck/encryptedgist
[2] HN submission: https://news.ycombinator.com/item?id=12475070
The recipient's identity is the key to opening the content - no need to communicate anything out-of-band. Depending on the file format chosen, you get DRM features limiting granular actions on the file beyond view/edit.
To open the protected files, your recipients will have to download/install the (free) app from Microsoft. This is generally pretty painless.
Definitely worth checking out, especially good for consultants' workflows.
Live link to try it out here: https://srpeck.github.io/encryptedgist/index.html
I had previously built similar games using other technologies, but found developing in q to be far faster, even given the more primitive debugging capabilities.
I understand that this is a relatively small example, but building it was enough to convince me the APL/k/q approach is useful beyond its supposed niche.
Also some good resources in this Quora: https://www.quora.com/What-are-the-best-resources-to-learn-q...
And if your interest is in the k language more than kdb+/q, then I have found the docs in John Earnest's ('RodgerTheGreat) oK interpreter a succinct, example-focused introduction: https://github.com/JohnEarnest/ok/blob/gh-pages/docs/Manual.... Plus using his browser-based REPL (http://johnearnest.github.io/ok/index.html) may lower the barriers to entry, and iKe (http://johnearnest.github.io/ok/ike/ike.html) is great for experimentation...http://johnearnest.github.io/ok/ike/ike.html?gist=9c5f43baa4...
https://github.com/JohnEarnest/ok/tree/gh-pages/ike
https://github.com/JohnEarnest/ok
And related APL/J/K subreddit: https://www.reddit.com/r/apljk/
The major enabling feature is that I do not differentiate between players and AI - both are networked clients (see here for the API docs: https://github.com/srpeck/kchess/blob/gh-pages/docs/kchessdo...). I wrote up some of my other design decisions here: https://news.ycombinator.com/item?id=10924316
And sorry, the live demo is currently down...but should be pretty quick/easy to run your own locally.
This is the reason I wrote Encrypted (https://github.com/srpeck/encrypted) - a single 21KB HTML file plaintext editor that uses SJCL to encrypt all data persisted to localStorage or disk. As a consultant I am often provided a work machine that I cannot install anything on - but there is guaranteed to be a browser.
This was my reasoning behind a spreadsheet prototype backed by kdb+ and the q language (which is a superset of SQL): https://github.com/srpeck/kxl
There is value in this simple combination, but tons of work required to gain feature parity and market share from Excel. I think the latter is why research in this space is lacking.
Plus, as a developer I would really like this model, as it allows the browser to open up even more of the operating system functions, especially the file system, leading to less workarounds.
For example, as an exercise to test the ability of code golf-style/APL/array programming languages to handle messy business logic, I recently built a 2D tick-based MMO in kdb+/q: https://github.com/srpeck/kchess
Note the design decisions/constraints that reduced development time:
- High programmer efficiency kdb+/q platform
- Simple client-server architecture
- All-on-one-box - kdb+ is both the front-end server and the datastore
- Websocket-based networking
- Tick-based - 1 second ticks to limit latency issues, though the server fully supports near-realtime ticks
- No differentiation between players and AI - both are networked clients (e.g., see here for the simple websocket client docs: https://github.com/srpeck/kchess/blob/gh-pages/docs/kchessdo...)
- No player identities (generally a commercial showstopper, but not for a side project)
- No 'content' - simple 2D graphics (though making the engine 3D would be trivial due to the vector paradigm), no progression/quests/RPG elements
Of course, there are the MMO pieces that generally increase development time:
- Game state cannot be globally fanned out given the sheer number of possible client connections (the first M - Massively)
- Untrusted players/clients
But once you have a simple, solid base engine, converting the result into an instance-based MOBA or a full MMORPG is not difficult, just time-consuming.
Here is one of my projects playing with that concept: https://github.com/srpeck/markdowned
Here is an MMO in kdb+/q that fits on a single Vim screen: https://github.com/srpeck/kchess
If you have truly sensitive information and/or regulations involved, you can layer RMS (Microsoft's DRM solution, could be additional purchase depending on subscription level) on top of SharePoint and get document-level encryption that follows files around and enforces your ACLs elsewhere. It uses your identity instead of a per-document password, which is a nicer UX.