| Age | Commit message (Collapse) | Author |
|---|
|
|
|
I don't like TODOs in my codebase, I'd rather keep them in org files. Eventually
I need a linter that prevents all TODOs from getting into code.
|
|
|
|
|
|
|
|
|
|
|
|
Rebuilt email server, started wireguard setup.
|
|
This also makes some changes to the build tooling to clean up the environment a
bit, and get us closer to 'bild -s'.
|
|
|
|
|
|
Getting me closer to the latest GHC. This release also includes my own packages
that I submitted some time ago.
GHCJS is not present in 21.05 for some reason, but I think it's back in master,
so I might do another upgrade soon, but for now I just disabled my GHCJS
support. I'm not really using it anyway.
I also had to bring it string-quote, update nixos-mailserver, and a few other
things.
|
|
|
|
|
|
|
|
I also upstreamed this to nixpkgs-dev
|
|
My router's DNS service likes to die, then I can't lookup any names, so let's
just use the public ones.
|
|
|
|
Every key is just a new line in the $USER.pub file. This is not automatically
reflected to gitolite, which uses a separate config, so I'll need to come up
with a way to replace gitolite someday.
|
|
|
|
Now bild knows how to determine between modules that require ghcjs and ghc. It
also knows what *not* to build, meaning it won't try to build non-buildable nix
targets, for example (unfortunately this is just hardcoded for now), but it also
won't build scm or py targets that I haven't implemented yet. It just silently
fails, which is fine, because it means I can do `bild **/*` and everything just
works.
Of course, if I want to build scm code then I will have to implement that, but
that's not a priority right now.
|
|
I had to refactor Biz/Bild/Rules.nix. I also had to checkin my patched
hoogle.nix file, but I also upstreamed the patch to nixpkgs-dev so it shouldn't
stick around for too long.
|
|
This includes deployment and implementation.
As part of sprint-49, here are the startup progress questions:
- Are you on track?
- Yes? I'm making progress toward a proper launch.
- Are you launched?
- No
- How many weeks to launch?
- I would say 4 but it's probably more like 8
- How many (prospective) users have you talked to in the last week?
- 2, Kyle and his manager, see below
- What have you learned from them?
- Kyle thought the metrics were interesting.
- His manager thought the metrics were kinda useful but didn't think they
really helped people ship higher quality code faster. So that's the rub: I
have to show how this can make devs ship higher quality code faster; or,
develop a set of features that improve those things.
- Kyle pointed out that the clustering feature of devalloc will find optimal
pairings *and* identify team silos that could be improved, so that's
important to remember and might be a good angle in the future.
- On a scale of 1-10, what is your morale?
- 6 maybe
- What most improved your primary metric?
- Well I was able to deploy something within in the week, whereas before I had
zero deploys per week. So that's an improvement.
- What is your biggest obstacle?
- Finding customers to talk to.
- Also the thing isn't really built yet, I just have a python script. I need
to build the real SaaS product
- What are your top 1-3 goals for next week?
- Find a single customer I can work with on an ongoing basis
- I should ask around my network to see if I have any second-order
connections that would be willing to work with me (Asher, Chad,
previous bosses, etc)
- Build out the front-end of the website (it's very simple, would just need a
basic miso module and deployment)
- Figure out how to connect/auth to the Github API so I can start building the
SaaS version of the product
Some user feedback from my friend Kyle. This comes from his engineering manager:
> "Looks neat. If it were priced low enough I could see using it to run reports
> as part of an overall package. A lot of those metrics don't matter too much to
> me as a manager though A lot of these code quality tools are handy info but I
> don't feel like they make people ship code any faster or any higher quality
> Things like CodeClimate work well for Jrs though to avoid obvious static type
> mistakes"
Kyle provided some additional comments:
> he might have been an unusual case. Jared's not big into metrics, Pivotal
> Tracker point estimates, or things like that... He's far more into qualitative
> feedback, like retrospectives and 1:1s
>
> I think it's definitely neat data! I certainly like the collaboration analysis
>
> It's interesting, we recently had a pair where two devs didn't work well
> together, that could be represented here. Though, we didn't want to avoid
> having them work together, we wanted them to find a work style that worked for
> both of them
And that's a good point: devalloc will find optimal pairings *and* points where
you could improve team cohesiveness.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also correctly renamed the files (didn't work the first time thanks to
the macOS filesystem) and moved the default build.os settings to a
OsBase.nix file to be used via imports.
|
