Very cool to see this progressing! I remember reading about this site in college. One tip, I think the HTTPS site is requesting HTTP resources for CSS/Google Fonts, which Chrome blocks, so I can't see the themes in their full glory :-)
JSON Resume – 5th Birthday and New Features
21–30 of 58 posts
Re: JSON Resume – 5th Birthday and New Features
#22Earlier quoted context omitted.
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…
> 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…
> Why not just one field?
Sales tax calculations by region.
Re: JSON Resume – 5th Birthday and New Features
#23Uh, there was already an XML format for this, I remember doing my CV with it. Nobody ever asked to see it or use it, so I stopped updating it. I learnt a few years later that some HR/recruiter systems do use it, behind the scenes, to talk to each other, they just never surface it. Why would this surface more often...? The HR industry is not made by coders, they live in MSWord and GDocs.
I'm thinking of using it (or a slightly hacked modification) because I keep a "master" resume in a messy LaTeX doc with lots of crap I usually filter out, and with variable accuracy in things like dates. But if I change careers, it will be useful because I'll have all that material ready to put back in.
Even while you're searching, having your different versions based on a single source of truth helps you keep everything consistent.
And you can then convert your source data to MSWord or other formats. It outputs HTML, so it's already a click away.
(Careful sending any easily editable format to some recruiters, they're liable to "enhance" it for you.)
Re: JSON Resume – 5th Birthday and New Features
#24Instead 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…
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 assembling that back together is culture dependant and depends on your use case. If you only need a simple name field that's easier.
Re: JSON Resume – 5th Birthday and New Features
#25It 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.
Re: JSON Resume – 5th Birthday and New Features
#26It 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.
Or lazy loaded json as stream of objects
Re: JSON Resume – 5th Birthday and New Features
#27Earlier quoted context omitted.
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…
> 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 abbreviation. Others make up nonsense and genuinely think what they have is correct. Developers and geeks aren't immune; I've seen forms that reflect an inadequate understanding of addresses.
Re: JSON Resume – 5th Birthday and New Features
#28Pro 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.
I use JSON to store my resume, and Latex to format it.
Here is a snippet:
```
\begin{luacode}
require("lualibs.lua")
local file = io.open('data.json')
local jsonstring = file:read('*a')
file.close()
local jsonData = utilities.json.tolua(jsonstring)
-- Header -- local personal = jsonData["personal"]
-- Education -- local education = jsonData["education"]
tex.print('\\section{Education}')
for key, value in pairs (education) do
tex.print('\\cventry{' .. value["year"] .. '}{' .. value["degree"] .. '}{' .. value["school"] .. '}{' .. value["location"] .. '}{}{' .. value["specialty"] .. '}')
```
Re: JSON Resume – 5th Birthday and New Features
#29Earlier quoted context omitted.
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…
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.
Re: JSON Resume – 5th Birthday and New Features
#30Uh, there was already an XML format for this, I remember doing my CV with it. Nobody ever asked to see it or use it, so I stopped updating it. I learnt a few years later that some HR/recruiter systems do use it, behind the scenes, to talk to each other, they just never surface it. Why would this surface more often...? The HR industry is not made by coders, they live in MSWord and GDocs.
I'm thinking of using it (or a slightly hacked modification) because I keep a "master" resume in a messy LaTeX doc with lots of crap I usually filter out, and with variable accuracy in things like dates. But if I change careers, it will be useful because I'll have all that material ready to put back in. Even while you're searching, having your different versions based on a single source of truth helps you keep everyt…
> (Careful sending any easily editable format
Of course, I only send PDFs (closest you can get to non-editable without going exotic).
Personally, these days I just export my LinkedIn bio and then tailor to the particular application. Unless LI starts exposing this, I have no real use for it.