| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Part of a larger effort, but doing this iteratively in smaller chunks.
|
|
This makes scanning logs *much* easier. I figure keep it as simple as possible,
just red, yellow, and green.
I also added two spaces between labels in the log messages. It would be nice to
have a more structured logging system, but for now this works.
|
|
|
|
This argument will run the tests for an output after building. It's active in
'ci' so running that will ensure tests are passing. This way testing a
namespace and building a namespace are as close together as possible, so
presumably it will be that much easier to write good tests.
|
|
Also changes the --test option to a 'test' command. This is because running the
tests for a namespace/exe should never be combined with anything else: you
either want to run the tests, or not.
|
|
|
|
|
|
Using lib.pipe for readability. Moved analyze into the public functions so I can
debug things easier by calling bild.analyze from the nix repl.
|
|
There is a bug in nixpkgs where lib.strings.splitString overflows on long lines.
builtins.split performs better, but needs the extra filter for some reason.
https://github.com/NixOS/nixpkgs/issues/68951
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Move them under the Biz root so that we know they are specific to Biz stuff. Biz
is for proprietary stuff that we own.
I also had to refactor the bild namespace parsing code because it couldn't
handle a namespace with 3 parts. I really need to get that namespace library
written and tested.
|
|
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.
|
|
|
|
|
|
|
|
|
|
I reorganized in order to debug a problem with the nix overlays. I think
having small, focused overlayes is more understandable than one overlay
that references itself via `rec`. Also the error traces are easier to
follow with smaller overlays.
|
|
|
|
|
|
|
|
|
|
|
|
Also had to capitalize some stuff, and move some nix files around and rename
the metadata directive from 'exe' to 'out' because that just makes more sense,
and fix some compiler errors. But now bild treats both nix and hs files as
buildable things. So that's cool.
One interesting example is Biz/Pie.{nix,hs} - I can either create a dev build of
the hs file with ghc, or I can create a fully-encapsulated nix build. Its nice
to have both options because a dev build with ghc takes half the amount of time,
and I can rely on my locally cached hi and ho files. I think this shows the
power of bild, but also can be a somewhat subtle thing.
The issue really is with the separate command calls in nix builds vs dev builds.
I figure there are a few ways to fix this:
1. Try to use bild inside the nix rules. That could be interesting, but could
also lead to some weird behavior or worm holes forming.
2. Extract the command line invocation into a separate file, some kind of
really simple template that gets pulled into both programs.
It is important to consider that in the future I might want to have bild do a
module-by-module nix build of programs, but I'm not sure how that would effect
my choice here.
|
|
|
|
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.
|
|
|
|
|
|
|
