5. Kit’s Origins
• 80% of the functionality needed produced
in one (alcohol fueled) weekend
• Very little Haskell knowledge
• No internet access, no guidance.
26. No.
• Plug through WriterT for Logging
• Remove IO from the Monad stack
• When IO is gone, define invariants in
quickcheck properties
• Learn how to specify those properties
through types
Notes de l'éditeur
\n
And getting better is easy\n
What Kit is\nCombines multiple dependency into one static library\nMuch easy to manage in Xcode\nEasier to manage individual deps through a KitSpec than using VC sub-modules\n\n
Explain what kit is\nUsed in mogeneration’s day-to-day app development. Crucial to version management of our apps and dependencies.\n
Not the best environment for cultivating good code.\n
\n
what does bad mean, in a haskell sense\n
This is a story of some the ways in which I’m making that happen.\nClearing out IO\nUsing other peoples code\nGeneral ugliness\n
First step in clearing it out is identifying what sort of IO you’re doing\nWhy is IO on a function? \nWhy is this bad? Side effecting functions are difficult to decompose\n
Why kit does: templates\n
Implementation writes a file to a particular sub-dir, needed to maybe create the sub-dir, and write the file.\nThis could be (and was) split up into a function that produces the content, and a function that writes the content. But at some point you still need IO deep in your application.\n\n
3 common file system ‘writes’\nLets me test content created, and where\nCleans up a lot of ‘create parent dirs, write file’ procedures\n
Every file writing operation now produces an FSAction, top level functions can be IO-less, and just have many actions to run, and each action can be tested (quickchecked)\n
next steps on clearing out IO, some of this as per tony, all are good for additional talks\n
Pretty typical milestone when you’re learning any language, is getting to grips with the std lib. Kit was written in a vaccuum... so lots of opportunities to improve on what it did initially\n
Dependencies form a tree\nCollapsing that tree in the wrong way caused bugs\n\n\n
Children are needed in the list before the parent, so lowest levels deps should come first\nNo duplicates\nbig TODO: version resolution\n
nub . reverse . tail . flatten\n
\n
\n
\n
I love applicatives, I love monads, and Kit does a *lot* of shell/FS access.\n\n\n
\n
Somewhat similar to package objects in scala (or a typical ruby project set up)\nUtil is probably a bad name\n\n
\n
Lots of things still to go, however the moral of the story (if there is one), is that it has been fairly easy to re-work parts of Kit to be better. Much easier than in other environments. Benefit of a very good type system...\n\n
