index.html.jst

   1 return async env => {
   2   let breadcrumbs = await _require('/_lib/breadcrumbs.jst')
   3   let navbar = await _require('/_lib/navbar.jst')
   4
   5   await navbar(
   6     env,
   7     // head
   8     async _out => {},
   9     // body
  10     async _out => {
  11       await breadcrumbs(env, _out)
  12
  13       h4 {'About Dr. Nick'}
  14
  15       p {'I have always been a technical guy, and I am usually found building something—unless I am spending quality time with my wife Laura or parenting a large brood of children. I like working with my hands, and equally my brain. And as I’m still using a physical keyboard, writing code allows me to do both!'}
  16
  17       h4 {'About this site'}
  18
  19       p {'This site serves as a repository for my open-source projects. Smaller projects will show up as a blog entry, and for long-term projects this expands to a project page, tutorials, online documentation and so forth. I would also welcome any contributions you may have.'}
  20
  21       p {
  22         'My '
  23         tt {'git'}
  24         ' source code repositories are at '
  25         a(href="https://git.ndcode.org") {'https://git.ndcode.org'}
  26         ', and eventually there will be an '
  27         tt {'apt'}
  28         ' repository there too, for the binary versions of my packages. My project pages contain the explanations of what things are, with links to the appropriate repositories. I prefer not to use github, as I do not like the idea of for-profit companies using my work to bring traffic to their site. I’d rather that traffic came to '
  29         i {'my'}
  30         ' sites, where I could monetize it later if I saw fit.'
  31       }
  32
  33       h4 {'About my coding style'}
  34
  35       p {'I like precision and I generally don’t leave unhandled cases in my code. (In my long career as a professional programmer I’ve encountered Murphy’s Law on a regular basis). I also prefer consistency in matters such as identifier naming, indenting and so on.'}
  36
  37       p {'Having said that, my emphasis is on productivity rather than dotting i’s and crossing t’s. So my code is generally quite rough until I decide it needs to be polished up for release. As an example, suppose I’m writing a language compiler. Any language features that I do not use will not be implemented and will crash with an assertion failure or similar. I rely on people like yourself to download and exercise my code and inform me of the features you’ll use.'}
  38
  39       p {'I also rarely use comments in my code. One of the reasons why I avoid commenting, is that often you spend inordinate amounts of time writing up the interfaces and algorithms used in your code in great detail in comments, and then change your mind and delete big blocks of code—along with those painstakingly constructed comments. If you do not invest too much in the code in the first place, it’s easier to delete and refactor.'}
  40
  41       p {'Comments will be placed where I had to stop and think, if I realize the thought process probably won’t be obvious later. But good code should be self-documenting in general. For this reason I often write out longer code for things that could be done with language tricks, and I avoid abbreviation. Usually this is enough to record my intentions for later. But sometimes I really can’t understand what I wrote, and once I’ve figured it out again, I will leave a belated comment for next time!'}
  42
  43       h4 {'About my testing style'}
  44
  45       p {
  46         'On this point I refer the reader to an excellent article, ‘'
  47         a(href="https://techbeacon.com/app-dev-testing/no-1-unit-testing-best-practice-stop-doing-it") {'The No. 1 unit testing best practice: Stop doing it'}
  48         '’. I do in fact use tests, and they are often to be found in a '
  49         tt {'/test'}
  50         ' or '
  51         tt {'/tests'}
  52         ' directory in my repositories, but the tests are only what I needed during development to exercise my code, and they might not be maintained once I am satisfied that the code works.'
  53       }
  54
  55       p {'The problem with unit tests that are required to be maintained (usually as a matter of company policy) is that once again, you have invested a lot in how the code works at the present time, and this makes it much harder to refactor it. You need to be agile and be able to fix things when you see a better way, not get mired in mountains of administrative detail.'}
  56
  57       p {'If the code fails in the field or I decided to work on it again, I will maintain and extend the tests as required. But my point is simply that testing is not an end in itself, it’s a means to an end (reliable software). The best means to that end, in my view, is end-to-end testing (E2E). E2E is absolutely the opposite of unit testing. E2E tests that outcomes are meaningful for users, whereas unit testing tests that 2 + 2 = 4.'}
  58
  59       h4 {'Why these projects?'}
  60
  61       p {'When I am working in salaried work, or for clients, usually I have to fit in to established practices. Some of these practices are useful, but many of them I disagree with, because I like to re-think things from first principles and decide what I will adopt and what I will not (and why).'}
  62
  63       p {'On the other hand, when I am working on my own projects, I am free to do things in a less-established or more radical way, if I think that my way is better. However, turning paradigms on their head is hard work, since you have to recreate things from scratch rather than standing on the shoulders of giants.'}
  64
  65       p {
  66         'I would aim for a sort of a happy medium where I use established tools such as '
  67         tt {'Linux'}
  68         ', '
  69         tt {'Python'}
  70         ', '
  71         tt {'node.js'}
  72         ', and the extensive infrastructure that comes along with them, to gain a measure of power and productivity, and then I use this power and productivity for rapidly prototyping new ways of doing things. But I would try not to add a lot of middleware layers like '
  73         tt {'docker'}
  74         ', '
  75         tt {'mysql'}
  76         ', '
  77         tt {'nginx'}
  78         ', and the like. I like building on the bare metal where I can.'
  79       }
  80
  81       p {
  82         'Eventually, I would like to build my own operating system, languages and applications to meet my day to day needs. Although this is too ambitious for the time being, it might become possible if I can develop more efficient ways of working. That’s essentially the rationale to the projects here—in particular:'
  83         ul {
  84           li {
  85             'The JST project allows to build websites efficiently.'
  86           }
  87           li {
  88             'The '
  89             span.serif {'π'}
  90             'tree project allows to build languages efficiently.'
  91           }
  92           li {
  93             'The LogJSON project allows to build databases efficiently.'
  94           }
  95         }
  96       }
  97
  98       p {
  99         'There are also some associated Computer Aided Software Engineering (CASE) tools that I built as examples, such as the '
 100         tt {'c_to_python'}
 101         ' tool which (roughly) translates C code into Python using the '
 102         span.serif {'π'}
 103         'tree framework. Having custom-built CASE tools can really turbocharge a refactoring project and make the impossible possible. I also think that CASE tools will help my longer-term goals of developing larger and more ambitious projects efficiently.'
 104       }
 105     },
 106     // scripts
 107     async _out => {}
 108   )
 109 }