| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Still calibrating my use of hlint.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I decided to finish the Devalloc frontend by just removing it. This way I can
have everything in one file, the code is much simpler, and I can scale up as
needed.
Anyway, this works fine with Turbolinks and that's pretty cool, so you get the
same basic feel as with any other SPA.
|
|
After hours of trying to get a page abstraction working in a Miso app (both
Devalloc and Hero) I had a revelation: Miso is an SPA - *single* page
application - framework, and so trying to put multiple pages into it is
fundamentally at odds with the rest of the architecture.
Of course this is also a problem with Elm's pattern of nesting models in order
to create a page abstraction. They can pull it off because they don't also try
to do isomorphic rendering.
In hindsight this should be obvious... if I actually do want some kind of
page-like abstraction or separation, then I need a much more complex server that
can embed different Miso apps based on some logic. But this is more like
multi-tenancy, or something.
Also I'm starting to think that I don't want Devalloc to be an SPA anyway, so
I'll try an experimental branch where I rip it out and just use Servant, Lucid,
and Turbolinks.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
