Interesting and possibly relevant to note that SQLite is not your typical opensource project:
"Open-Source, not Open-Contribution: SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. The project does not accept patches. Only 27 individuals have ever contributed any code to SQLite, and of those only 16 still have traces in the latest release. Only 3 developers have contributed non-comment changes within the previous five years and 96.4% of the latest release code was written by just two people. (The statistics in this paragraph were gathered on 2018-02-05.)"
If we accept patches, then the person who has submitted the patch owns the copyright on that patch, and that means the software is no longer completely in the public domain. Unless, of course, the patch submitter has filled out a lot of legal paperwork to dedicate their code to the public domain, which rarely happens.
> In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches. If you would like to make a suggested change, and include a patch as a proof-of-concept, that would be great. However please do not be offended if we rewrite your patch from scratch.
The fact that it doesn't can be exploited by running it in a virtual machine and using the snapshot feature to go back in time. That's how we made this Website is Down video: https://www.youtube.com/watch?v=1SNxaJlicEU
Will this technology be licensed for redistribution or only for online API use? I ask because in the video game scenario it would be great to have this in a library I could distribute instead of relying on the API to be available at all times.
Interesting... so there no security concern with using HTTPS on a public Wifi? I thought there was some way the connection could be hijacked. Thanks for the response.
I am surprised at the number of people who think they can do everything without a framework and that everything would just be better if they weren't weighed down by the horrible affliction of using one. Frameworks provide real value and while not required for many small applications they can be a huge advantage in large enterprise applications.
For example if you are using Ember you gain the advantage of a client-side ORM called Ember Data which handles caching and cache invalidation for your API data. Did you handle that in your non-framework application? If you did, how long did it take you to implement? How well tested is it? How many developers besides yourself have reviewed it? How much documentation did you write and how long does it take to bring new developers up to speed on it? If it breaks, who will fix it?
Multiply that by ten or twenty depending on the framework and you start to see what the benefits are.
I always liked Brian Moriarty's definition of story: "a particular causally related sequence of events".
Which certainly does allow for a conflict free story. The important thing is that a story has events which are causally related. Otherwise it really is just a list of unconnected statements.
> I always liked Brian Moriarty's definition of story: "a particular causally related sequence of events".
By this logic, it seems that a recipe is a story. (Maybe that's intentional!)
I'd almost view the definition of a story as more about the intention than about the content—rather like art, which can (arguably) be created simply by the act of presenting it as such (in the sense of "found art" (https://en.wikipedia.org/wiki/Found_object )). So too, surely, can one have a "found story".
This reminds me of some words of advice I noticed in an even older manual for the Apple II floppy disk drive:
"To load a program named AGATHA, use the command LOAD AGATHA
and the program of that name, if there is one in the catalog, will be loaded. To test if AGATHA is loaded, see if it can walk along a straight line."
Someone wrote (and then apparently deleted) an interesting comment pointing out this was originally written by Jeff Raskin in the 'Apple II Basic Programming Manual'.
The screenshots are from a later version called 'The Applesoft Tutorial', revised by Caryl Richardson. That version has no author credits.
"Open-Source, not Open-Contribution: SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. The project does not accept patches. Only 27 individuals have ever contributed any code to SQLite, and of those only 16 still have traces in the latest release. Only 3 developers have contributed non-comment changes within the previous five years and 96.4% of the latest release code was written by just two people. (The statistics in this paragraph were gathered on 2018-02-05.)"
https://www.sqlite.org/copyright.html