| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
