JSON Configurable Personal Site(github.com)
github.com
JSON Configurable Personal Site
https://github.com/christophior/JSONConfigurablePersonalSite
5 comments
Great to see a fellow PayPal Austinite on HN Chris! For a lot of people really quick and easy way to have a personal site up and running. Couple suggestions, possibly add system requirements and deploy instructions (possibly deploy to heroku/or deploy to digitalocean button) ?
Just saw this, thanks for the suggestions Avi! I'm currently messing around with it, I was already looking into one click deploy. I recall some time prior that Github unveiled a one click deploy button so I was going to try and integrate that into the repo.
You know you could do this as a Jekyll site, right? And then you wouldn't even need to install Jekyll, you could just put everything on GitHub and it would render it for you. Then you could let people fork and modify the links and they would have their own sites too, without even downloading anything.
Doing these with a backend is not fun at all: it is too easy to program (you know that with a node server you could do way more than a "JSON configurable personal site"), but it also consumes too much resources to run. So if you could do it without a backend, why not?
Doing these with a backend is not fun at all: it is too easy to program (you know that with a node server you could do way more than a "JSON configurable personal site"), but it also consumes too much resources to run. So if you could do it without a backend, why not?
Never used Jekyll before, thanks for the heads up. I'll look into it.
It is not that I like Jekyll, but that GitHub pages supports it -- and compiles its sites on every deploy --, so it works well.
Do we know what's behind this on the server? Is this a Node.js thing? (perhaps obvious to many, but I'm not down with the server-side js scripting and templating lingo.)
Creating a site from a json file sounds good. I defintely want to play with that, but what is required on server?
Creating a site from a json file sounds good. I defintely want to play with that, but what is required on server?
The site is a node app, so you would need node and npm (the package manager for node) on your system.
I hate editing JSON by hand. Why not YAML?
I think TOML[1] is a strict upgrade of JSON as a configuration file format. It has exactly the same expressiveness, but much more human-readable.
[1] https://github.com/toml-lang/toml
[1] https://github.com/toml-lang/toml
Jekyll uses YAML, which brings me to the question, what does this do besides JSON that Jekyll doesn't?
I converted this project to Jekyll, using YAML as the config and hosted on Github Pages: https://github.com/DDuarte/JekyllConfigurablePersonalSite
I work at Apiary and we have a format called MSON for writing data structures in Markdown.
https://github.com/apiaryio/mson/
https://github.com/apiaryio/mson/
Agree completely.
I have had to configure some relatively large forms in an application using JSON. Its not a particularly easy to read format, and when the nesting is deep its easy to loose a brace, or not notice a trailing comma in a list.
(I don't know if YAML solves all of those problems, but it certainly looks easier to read).
I have had to configure some relatively large forms in an application using JSON. Its not a particularly easy to read format, and when the nesting is deep its easy to loose a brace, or not notice a trailing comma in a list.
(I don't know if YAML solves all of those problems, but it certainly looks easier to read).
yeah especially when you have nested arrays of JSON objects with a dozen fields with very long text content....simple in practice but not very readable or clean for humans.
Came here to say exactly the same. It's so easy to support both and for anything where a human is expected to edit it by hand then YAML is far less user-hostile.
I can give you my own reasons. I avoid YAML because it's not simple like JSON.
Just look at the YAML spec - http://www.yaml.org/spec/1.2/spec.html
compared to JSON - http://json.org/
and JSON is already everywhere (as a built-in library, a known mime type, etc). I have to go out of my way in order to use YAML.
I guess the other reason is that I never trust projects with names like "Yet Another..." because I feel like it conveys a lack of craftsmanship. Looking at that YAML spec again today, it looks like every feature was thrown into it with little to no discrimination.
Just look at the YAML spec - http://www.yaml.org/spec/1.2/spec.html
compared to JSON - http://json.org/
and JSON is already everywhere (as a built-in library, a known mime type, etc). I have to go out of my way in order to use YAML.
I guess the other reason is that I never trust projects with names like "Yet Another..." because I feel like it conveys a lack of craftsmanship. Looking at that YAML spec again today, it looks like every feature was thrown into it with little to no discrimination.
The parts you generally use and the length of the spec are entirely different things. This argument is always silly.
There's no need to be rude about it. Your first statement would have sufficed to make your point.
Anyway, I didn't say that I don't use it because of the length of the spec. I said I don't use it because it's orders of magnitude more complex than JSON and I used the spec as an example of that. A bigger spec means a bigger parser and a higher probability that other people will not limit themselves to the parts that "you generally use".
To that, I added that JSON is everywhere already and YAML isn't. My point about the name seems a little silly, but my intuition has served me well over the years.
Anyway, I didn't say that I don't use it because of the length of the spec. I said I don't use it because it's orders of magnitude more complex than JSON and I used the spec as an example of that. A bigger spec means a bigger parser and a higher probability that other people will not limit themselves to the parts that "you generally use".
To that, I added that JSON is everywhere already and YAML isn't. My point about the name seems a little silly, but my intuition has served me well over the years.
To be a 'compliant' parser, you generally have to implement the whole spec. The bigger the spec, the more complicated the parser. The less stuff from the spec you use, the less gets tested. What's silly is picking a 'standard' and thinking because you only use a little bit, you're safe.
Just a nitpick. YAML stands for "YAML Ain't Markup Language".
It started out as "Yet another markup language" though - http://yaml.org/spec/history/2001-05-26.html#sec-intro
I don't understand why we should use JSON to configure a server, when a much more powerful language exists: Javascript.
For example, instead of hardcoding some setting in JSON, a Javascript configuration file could perform queries before configuring, or it could install callback functions as part of the configuration.
For example, instead of hardcoding some setting in JSON, a Javascript configuration file could perform queries before configuring, or it could install callback functions as part of the configuration.
> I don't understand why we should use JSON to configure a server, when a much more powerful language exists: Javascript.
Because it's more powerful. More powerful, in many cases, is a worse thing. Executable imperative code isn't as flexible as a data file because all you can really do with it is execute it and take the output, rather than process it as you see fit.
See:
Rule of Least Power – https://en.wikipedia.org/wiki/Rule_of_least_power
Principle of Least Power – http://c2.com/cgi/wiki?PrincipleOfLeastPower
Because it's more powerful. More powerful, in many cases, is a worse thing. Executable imperative code isn't as flexible as a data file because all you can really do with it is execute it and take the output, rather than process it as you see fit.
See:
Rule of Least Power – https://en.wikipedia.org/wiki/Rule_of_least_power
Principle of Least Power – http://c2.com/cgi/wiki?PrincipleOfLeastPower
These articles are phrased as if they are facts. However, they are just some opinions that some people feel are useful.
Take for instance the idea of the "semantic web", where information is stored neatly into proper html tags. It has turned out that this is not a very useful approach to storing information, and nowadays big search engines use machine learning techniques instead to extract the information.
Take for instance the idea of the "semantic web", where information is stored neatly into proper html tags. It has turned out that this is not a very useful approach to storing information, and nowadays big search engines use machine learning techniques instead to extract the information.
I don't understand why we should use JS to configure a server, when a much more pleasant language exists: Python.
Ultimately, it's not about the language, it's about the simplicity. If you need more that what this does, you can go out and do that, but this looks like a wonderfully simple system where I can just write some information about myself and it uses that to build a site.
Ultimately, it's not about the language, it's about the simplicity. If you need more that what this does, you can go out and do that, but this looks like a wonderfully simple system where I can just write some information about myself and it uses that to build a site.
there's one more step before that and it is YAML.