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