-
Like others, the problem solving and constant learning was what drew me, but now having had a few years of experience, what makes me happy and eager to work is when I am allowed to do the best I can instead of compromising quality in the name of shipping. I know nothing I do will persist, but making my best effort is what enables me to continue to hone my skills, and feel some sense of personal development.
-
There’s an interesting cycle in the learning of a language. Few sources use or mention rebar3 because they come from a time before it. We (Tristan Sloughter and myself) developed it during our time at Heroku, and even though we have both left, we still maintain it.
Books like Learn You Some Erlang not only pre-date rebar3, they initially were written in part or entirely before any build system whatsoever (aside from custom makefiles) even existed.
That being said, I’m glad the current ecosystem is proving welcoming and motivating for developers :) Keep on trucking Damien.
-
-
We do have graph editors, they’re just all proprietary and/or use some arcane format that isn’t nearly as straightforward as text encoding.
-
Yup, I faced this problem 6 months ago.
Even though they are far from being perfect, there are some FOSS graph editors.
Gephi: https://github.com/gephi/gephi is really nice. The problem I have with it is its stability. Other than that, you can edit and analyse gigantic graphs from a single tool, which is really nice.
I agree with you about the format problem. Even though graphml is quite widely supported, getting interoperability using that format is quite hard, mostly because of poor implementations. For instance, pygraphML (https://github.com/hadim/pygraphml) which is the de facto standard graphml for python and gephi’s graphml importer are not compatible (problem with the nodes labels if I remember correctly).
-
Depending on what area you’re in, GraphML may not even be feasible. I work with a good deal of social network data, and encoding any remotely large dataset in GraphML would be insane both in terms of parsing time and disk usage.
A large/medium (depending on who you ask) dataset I use for testing is nearly 50GB in ye olde edge list format, which takes about 20 minutes to read and parse. GraphML would take even longer. I use a binary format which reduces it to about 12GB and which takes 15-30 seconds to read depending on disk speed.
This is fundamentally why there are so many different formats for graph/tree data: such a general structure sees usage in a huge variety of fields, and therefore there are a huge variety of requirements for what it can represent, how efficiently it needs to do so, etc. No one format can possibly meet all of these requirements.
-
-
-
-
In erlang, just because! https://github.com/igaray/toolkit/blob/master/erlang/sphere_tesselation/mesh.erl
In abstract, I usually take a hybrid top-down / bottom up approach. I usually map out the major components to the system, and list all inputs and outputs at the system borders (configuration, HTTP endpoints, sockets, library api’s, databases, temporary files, etc), and then start to work on one part and map that out in greater detail, filling out the high level overview with detailed knowledge.
Callgraphs, dependencies, and as irfansharif mentioned flamegraphs are good visualization options. There may be language-specific tools for you.
Ask your peers many questions! Aside from ‘how’, ‘why’ is probably the most important. Write them down. Keep a daily dev journal in which you ask and answer questions to yourself. Document what you learn as you go along and make the journey for the next one easier.
Setting up the codebase gives you more practical knowledge about running the code. Writing toy code that makes use of the codebase gives a very high level of return on time investment. Sometimes you have to write code to understand what you are reading, and active engagement with any knowledge make it stick more than just passive intake. Make small refactors, even if you don’t commit them back to the main repository.
Don’t despair! Getting to know a codebase takes time and experience, and some ramp up time is always expected.