Hacknical: turning a GitHub commit history into a resume page

The pitch is a resume built from your commit graph

Hacknical is described as a website for GitHub users to generate their GitHub data analysis, covering contributions, commits, languages and repository data, to help make a better resume. The live site is hacknical.com and the repository description puts it as hacker & technical.

The concept is straightforward. A candidate's GitHub activity is public, but a GitHub profile is not a resume: it shows repositories, it does not show a line of work, a contribution graph over time, or a breakdown of which languages they actually work in. Hacknical takes that activity and lays it out as a personal site with a resume section.

The README points at a worked example, the author's own GitHub data analysis page, and shows screenshots of the login page and of the analysis page. Most of the pages now support English, including the GitHub data analysis page, and there is a Chinese version of the README at doc/README-ZH.md alongside an About page in Chinese at doc/ABOUT-zh.md.

The feature list is short and worth reading as a to-do list with the current state marked. Support for English is done, support for orgs is done, support for showing the resume on mobile is done, and support for exporting the resume to PDF is done. Support for forked repositories is not done, and neither is editing the resume on mobile.

That list tells you the shape of the product. The analysis side is mature, the resume side works on desktop and exports to PDF, and two obvious gaps remain, one of which is the forked repository problem, which is a real limitation for anyone whose visible work lives in forks.

The GitHub crawling and the UI components are separate projects

The repository explicitly does not contain everything. The README has an Extract dependency section that points at two other repositories.

The UI components come from light-ui, and the GitHub API crawler comes from hacknical-github. Both are under the same author, ecmadao.

This split is worth understanding because it changes what you inherit when you clone this repository. The app/ directory holds the server, the frontend/ directory holds the React code, and the actual calls to the GitHub API live in a separate package that you have to bring along yourself. The same is true of the shared UI components.

It is a reasonable factoring if you want to reuse the crawler on its own, for example in a different front end, or to use the component set in another project. It is a cost if you want to run this application, because the setup instructions have to account for three repositories rather than one, and the versions have to line up.

The top level entries confirm the shape. There is app/, frontend/, config/, public/, scripts/, doc/, a .babelrc for the Babel configuration, an .eslintrc and .eslintignore for linting, and a package.json at version 1.7.6.

The application entry point is dist/bin/app.js, which tells you the server is compiled with Babel from the app/ directory into dist/ before it runs.

A Koa backend with Mongo, Redis and Nunjucks templates

The tech stack is listed in the README and it is specific enough to describe the architecture.

The backend runs koa2 with redis, mongoose, nunjucks, request and pm2. So it is a Node HTTP service, mongoose is the MongoDB object mapper, Redis is doing something on the side, most likely caching GitHub API responses, nunjucks is the server-side template engine, request is the outbound HTTP client used for the GitHub calls, and pm2 is the process manager.

The frontend runs react with redux for state, react-router for routing, chart.js for the graphs, particles and scrollreveal for the visual effects, clipboard and headroom.js for small UI behaviours, and webpack as the bundler.

Two of those choices are worth a comment. chart.js is how the commit and language breakdowns become graphs rather than tables, which is the entire visual identity of the site. And particles, which is a canvas particle animation, is the kind of thing that either makes a developer portfolio feel alive or looks like a 2015 splash screen, and there is no configuration hint in the visible documentation either way.

The build scripts in the package.json show how the two halves are compiled separately. The server is built with Babel, from app to dist with files copied, and the frontend is built by webpack with separate production and development configurations plus a DLL build for the vendor bundle.

"build-app": "babel app -d dist --copy-files",
"build-static": "npm run build-dll-pro && npm run build-src",
"build-src": "bnr pro:build:src"

The betterScripts block is the mechanism: bnr is a script runner that expands named tasks, and the pro: and local: prefixes separate the production and development variants of each task, each with its own NODE_ENV and its own webpack config.

The scripts show how it is run and how it is deployed

The npm scripts describe the whole lifecycle, and they are unusually informative about the deployment shape.

Development is start-dev, which builds the webpack DLL bundle and then starts the app, and start-app, which runs the local app start and the source build in watch mode. Production start is a single task running the production app start through bnr. There is a matching stop task.

The production app start command, visible in the truncated script block, runs forever with a kill signal of SIGTERM, with the application name and log paths set to a specific directory under /var/log/ecmadao/hacknical, and an error log path under the same tree. That tells you the deployment assumes a fixed server with a specific path layout and a process manager keeping the Node process alive.

The deploy script is the most revealing line in the file.

"deploy": "git checkout master && git pull origin master && npm i && npm i --only=dev && bash ./scripts/deploy.sh"

It checks out master, pulls, installs both production and dev dependencies, and then runs a shell script from the scripts/ directory. That is a deploy by git pull on the server itself, which means the server has the repository checked out and writable, and the release process is a pull rather than an artefact upload.

The lint script runs eslint over the frontend and app directories separately, and precommit runs lint, so the lint gate is enforced on commit rather than only in CI.

There is no test script in the package.json at all, which is worth noting for anyone planning to modify the code rather than just run it.

Why the project froze and where the maintained version lives

The most important content in the README is the banner at the top, and it should be read before anything else.

The repository is now in maintenance freeze mode and will receive limited updates going forward. For a more actively maintained version with better ongoing support, the project points at two things: the repository liguobao/hacknical, and the online website hackneo.cn.

That is an unusual situation for a project to be in, since the fork is by a different author rather than the original maintainer, and the hosted site is not hacknical.com but a different domain. In practice it means the deployment people actually use is not this repository, and anyone starting fresh should look at the fork rather than this one.

The Apache-2.0 licence is one of the more permissive and widely accepted licences, and the LICENSE file is at the repository root. That removes the licensing question that would otherwise complicate a fork, and it is not legal advice but it is an unusually clean position for a project whose main asset is its code.

The last push was on 2026-10-09, which is recent in absolute terms but consistent with the freeze: the tree still receives commits, presumably small ones, while the product direction has moved elsewhere. The repository has no GitHub releases, so the version in package.json, 1.7.6, is the number to rely on.

Where Hacknical is the wrong tool

The obvious limit is the one the banner announces, and it is decisive.

For anything you intend to run and keep running, this is the wrong repository, because the project has told you it is frozen and pointed somewhere else. Installing it and maintaining it yourself means owning a Node application with a Babel build, a webpack build, a MongoDB, a Redis and a pm2 process, with no test suite to catch your regressions, and no upstream to send you a security fix for the GitHub API integration.

The second limit is that the analysis is derived from a public API and nothing more. Hacknical reads your GitHub activity, so it can only show what GitHub already shows. It does not know what you did in a meeting, what a project was for, or what a particular commit meant, and it does not give you a place to write any of that. The resume it produces is a rendering of activity, and a hiring manager reading a contribution graph learns something different from a hiring manager reading a project description.

The third is that the design assumes a public profile. The login flow exists so the site can fetch private or organisation data, and support for orgs is marked done, but a person whose work is deliberately not public gets an empty page, and a person whose visible work is in forks gets an incomplete one because forked repository support is still an open item.

The alternative for the same goal is to write the resume by hand and use a static site generator for it, which takes longer once and produces something that reflects how you want to be read rather than how you happened to commit. The GitHub profile picture is a nice complement to a resume, not a replacement for one. If you want the automatic version, the maintained fork and its hosted site are the versions to look at, and if you want the diagram, a contribution graph service with a static resume template gives the same picture with none of this infrastructure.

Editorial conclusion

Hacknical suits a developer who wants a personal site assembled from public GitHub activity in an afternoon, and the fact that the data all comes from the GitHub API means there is nothing sensitive to host. It does not suit anyone building on it for production, because the project states it is in maintenance freeze mode with limited updates and points at liguobao/hacknical and hackneo.cn as the maintained alternative. Before adopting it, check that alternative first, and if you do run this version, plan for the missing features, since support for forked repositories and mobile resume editing are both still open items in the project's own todo list.

Frequently asked questions

Official sources

1. ecmadao/hacknical on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README