Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Resume – 5th Birthday and New Features

jsonresume.org

Post reply on HN
Print view View original

31–40 of 58 posts

Re: JSON Resume – 5th Birthday and New Features

#31

Post by wongarsu »

bvda wrote: post #29
wongarsu wrote: post #24

Earlier quoted context omitted.

I've always gone with title, first name, middle name(s), last name, suffix; all optional (or requiring that at least one of first and last name exists), all representable in Unicode, space allowed but no line breaks, each part no longer than 300 characters. In theory that might not cover everything, but I've never been able to come up with a counter example. Schema.org seems to take a very similar approach. Of course…

Is there any reason not to use a singular field for this? It seems so much simpler to just give the user one input field and it would cover all scenarios.

Apparently a single field works fine in a resume builder. But consider a more complex app that does all of the following: display the name in various lists, has a detail view on that user, greets the user, talks about the person in third person (a report or similar). In each of those cases you ideally want to treat the name differently.

Even in English the detail view might show George Walker Bush Jr (the legal name as the person might input it), while in the list you have to safe space and revert to George W. Bush. Greeting the person as "Hello George Walker Bush Jr" is silly, you want to say "Hello George" or "Hello Mr. Bush", depending on how formal you want to be.

In languages such as Japanese you might end up generating honorifics on the fly. You can't do that if you can't parse the name.

Re: JSON Resume – 5th Birthday and New Features

#32

Post by 0xJRS »

irrational wrote: post #25

It took me way too long to realize resume meant résumé (written summary of my experiences) instead of resume (to continue)! I was thinking JSON Resume was the next version of JSON, maybe adding the ability to have comments in JSON.

Its not super great but i’ve become a fan of doing this:

{ “name”: “Michael Scott”, “age”: 40, “_comments”: [“”] }

Re: JSON Resume – 5th Birthday and New Features

#33

Post by matthewbauer »

pknopf wrote: post #12

Pro tip, just creating your own schema. Tailor it to your theme. Here is my resume (as YAML): https://github.com/pauldotknopf/resume/blob/staging/resume.y... This file is consumed and used in a very small ad-hoc project, specifically for my format: https://github.com/pauldotknopf/resume/blob/staging/statik-r... Here is the final result: https://resume.pknopf.com/ Easy maintenance. Maximum flexibility. Low tooling.

LaTeX + ORG mode is an easy way to get some literate programming features while also still using a real typesetting engine. You can reuse my setup here:

https://github.com/matthewbauer/resume

Re: JSON Resume – 5th Birthday and New Features

#34

Post by toyg »

0xJRS wrote: post #32
irrational wrote: post #25

It took me way too long to realize resume meant résumé (written summary of my experiences) instead of resume (to continue)! I was thinking JSON Resume was the next version of JSON, maybe adding the ability to have comments in JSON.

Its not super great but i’ve become a fan of doing this: { “name”: “Michael Scott”, “age”: 40, “_comments”: [“”] }

Literally the "hot comments" pattern ;)

Re: JSON Resume – 5th Birthday and New Features

#35

Post by einrealist »

thomasfromcdnjs wrote: post #13
goblin89 wrote: post #7

Instead of going with an ad-hoc schema, I wish JSON Resume built on top of data structures standardized by Schema.org. They cover most of the concepts required— https://schema.org/Person , https://schema.org/skills , https://pending.schema.org/knowsAbout , the list goes on. For concepts not covered by Schema.org (I spotted only one, “interests”) the project could implement custom extensions until they are adopted by…

I personally don't disagree, we've always thought it best to leverage other peoples work first. Though one of the largest discussions we had on the specification was the definition of what a name was -> https://github.com/jsonresume/resume-schema/issues/4 After everyone's input, we decided to just opt for one field `name` because simply first/last/family name does not work across cultures. When we looked at schema.or…

You don't have to use the schema of schema.org. You can provide your own semantics (and build on pre-existing ones, like schema.org). The point is that you can provide information that is human readable and machine-processable (either through HTML or formats like JSON-LD).

Re: JSON Resume – 5th Birthday and New Features

#36

Post by bvda »

wongarsu wrote: post #31
bvda wrote: post #29

Earlier quoted context omitted.

Is there any reason not to use a singular field for this? It seems so much simpler to just give the user one input field and it would cover all scenarios.

Apparently a single field works fine in a resume builder. But consider a more complex app that does all of the following: display the name in various lists, has a detail view on that user, greets the user, talks about the person in third person (a report or similar). In each of those cases you ideally want to treat the name differently. Even in English the detail view might show George Walker Bush Jr (the legal name…

Ah interesting, I hadn't thought of those use cases.

Re: JSON Resume – 5th Birthday and New Features

#37

Post by heinrichhartman »

Aside:

> resume export resume.pdf (Currently broken, help needed)

https://jsonresume.org/getting-started/

Any news here?

Still puzzling to me, how hard it is to generate PDF documents. I assume this is not using Latex, since that would be a gigantic dependency to pull in. What is/was jsonresume using? Why did it break?

PS: Also pdf export on wikipedia has been broken for years now. Seems to be a hard problem.

Any information about light-weight pdf generators that work and produce decent pdfs documents would be appreciated.

Re: JSON Resume – 5th Birthday and New Features

#38

Post by icxa »

nulbyte wrote: post #27
Jean-Philipe wrote: post #15

Earlier quoted context omitted.

> After everyone's input, we decided to just opt for one field `name` because simply first/last/family name does not work across cultures. Thank you so much for this! Me and family members struggle filling forms because of this on a regular basis. Another pet peeve of mine are address fields. Why not just one field? People are smart enough to write down their address. Not everyone has a zip code or a street number, o…

> People are smart enough to write down their address. Not usually. In this scenario, given its use for display on a user page, it may make sense. For most other cases, this doesn't pan out. Here in the US, for example, the general public has little sense of how to properly write addresses with floor, apartment, unit, or suite numbers. Folks routinely put things in the wrong order or use the wrong symbol or abbreviat…

Yeah, if you work for a company that has to run any kind of validation on addresses, you learn quickly most people cannot type their address in correctly at all. My take: Make it as dumb and straightforwardly painfully obvious as possible.

Re: JSON Resume – 5th Birthday and New Features

#40

Post by paultopia »

pknopf wrote: post #12

Pro tip, just creating your own schema. Tailor it to your theme. Here is my resume (as YAML): https://github.com/pauldotknopf/resume/blob/staging/resume.y... This file is consumed and used in a very small ad-hoc project, specifically for my format: https://github.com/pauldotknopf/resume/blob/staging/statik-r... Here is the final result: https://resume.pknopf.com/ Easy maintenance. Maximum flexibility. Low tooling.

Yeah, I've done the same, though I kind of went egregiously over the top (academic website with vue.js + tex resume with all kinds of machinery generated from a bunch of yaml files): https://github.com/paultopia/websiterevision2017
Post reply on HN