| Age | Commit message (Collapse) | Author |
|---|
|
This is rough, I should move it up in the directory hierarchy and clean up the
nix files, but that can all come later. Just gonna test it out for now. Will
announce it tomorrow afternoon.
|
|
Well except for the redirect, but that's an annoying part of the cgit
implementation which will hopefully go away at some point.
|
|
|
|
|
|
- notes about dovecot and ssl certs
- disable matrix because its not setup properly and i don't use it
- format some stuff
- fix path to git repos
|
|
|
|
|
|
Rebuilt email server, started wireguard setup.
|
|
All the channels I like are defunct anyway.
|
|
|
|
This makes it explicit that we are using GitHub vs some other OAuth args. The
idea is that we should be making a new type for every service, this allows us to
have type safety in the implementation but a common set or pattern of names for
the environment variables and record fields.
Also using 'notset' instead of 'mempty' is really helpful for debugging when
this breaks, as I found out.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Also I need more repos...
|
|
|
|
Publicity is marked by the presences of the git-daemon-export-ok file.
|
|
This way I can develop on nixpkgs directly, and directly send patches upstream,
instead of trying to copy files back and forth and work with overlays.
Of course with private stuff that I will never publish, I should use overlays,
but that will probably not be very many things, I imagine.
|
|
Also adds a post-receive script that creates and publishes a git-archive of the
repo at that commit. This way I can depend on my own nixpkgs fork.
It took me forever but I finally figured out that I need --prefix in the git
archive. I also switched to using gzip instead of xz because its faster, and I
figured out how to get the sha256 that nix expects, so I can now just copy that
and paste it into Biz/Bild/Sources.json.
|
|
The correct way to do this would be to use my own nixpkgs fork published
at git.simatime.com, but to do that I need to setup a public git repo,
so until then I have to do it this way, which is fine.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
This is somewhat experimental, the idea is automatically set the sources
from my niv pinned deps. It seems to work, so I'll keep at it and see if
I can improve it as issues come up.
|
|
|
|
|
|
Moving away from the DNS-driven namespacing toward more condensed names,
mostly because I don't like typing so much.
|
