| Age | Commit message (Collapse) | Author |
|---|
|
I'm also just using the que.run stylesheet for now. Eventually I should make
this a base stylesheet, instead of nesting it under Biz/Que, but that can come
later.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Also I need more repos...
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
