h4 {'About Dr. Nick'}
- 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!'}
+ p {'The NDCODE project founder is Dr. Nick Downing. Nick has always been a technical guy, and he is usually found building something—unless he is spending quality time with his wife Laura or parenting a large brood of children. Nick enjoys working with his hands, and equally his mind.'}
+
+ p {'Nick’s background is in embedded software and hardware. This shows in his focus on writing efficient code that uses minimal resources. Nick was creating networked point-of-sale systems long before the Internet became a thing. Since then he has become an Internet of Things (IoT) expert.'}
+
+ p {'As well as his successful industry career, Nick holds a PhD in Computer Science from the University of Melbourne, with specializations in Pure Mathematics and Business. Nick is an effective teacher and has taught all aspects of Computer Science to subsequent students at the University.'}
h4 {'About this site'}
- 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 feedback or contributions you may have.'}
+ p {'This site serves as a repository for open-source projects. Smaller projects will show up as a blog entry, and for longer-term projects this expands to a project page, tutorials, online documentation and so forth. The project would also welcome any feedback or contributions you may have.'}
p {
'Public '
a(href="https://git.ndcode.org") {'https://git.ndcode.org'}
', and eventually there will be an '
tt {'apt'}
- ' 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 '
- i {'my'}
- ' sites, where I could monetize it later if I saw fit.'
+ ' repository there too, for the binary versions of packages. Project pages contain the explanations of what things are, with links to the appropriate repositories. We host our own repositories because we are opposed to the idea of for-profit companies leveraging our work to bring valuable traffic to their sites.'
}
h4 {'How to contribute'}
p {
- 'Patches can be emailed to me at nick ‘at’ ndcode ‘dot’ org, and I can give '
+ 'For a casual contribution please send patches to nick ‘at’ ndcode ‘dot’ org. We can give '
tt {'git'}
- ' write access to trusted contributors. I do '
- i {'not'}
- ' favour the new-fangled way of forcing people to contribute via Pull Requests (PRs) on github. At least in my case, this discourages contributions in the first place, because it becomes the contributor’s responsibility to edit the patch into an acceptable form and to push it through the system. I am grateful for any contribution you can provide, however rough, and if I think it’s not ready for merging then I will improve it or otherwise handle the situation as I see fit.'
+ ' write access to trusted contributors. Note that we do not use Pull Requests (PRs). Besides being excessively bureaucratic, the use of PRs tends to shift the responsibility onto a contributor to push his/her contribution through the system. We see this as a shared responsibility, not just the contributor’s.'
}
h4 {'Copyright and licensing'}
- p {'The projects on this site are open source and they are mainly MIT licensed or GPLv2’d. Generally, anything you might want to use in production will be MIT licensed, to give you complete freedom. Things you would only use in the development stage, such as code generators, are more likely to be GPLv2’d, but with appropriate exceptions to allow unrestricted use of the generated code. I don’t use GPLv3, as I regard the anti-Tivoization clauses to be too strict.'}
+ p {'The projects on this site are open source and they are mainly MIT licensed or GPLv2’d. Generally, projects you would use in production will be MIT licensed, to give you complete freedom. Projects you would use in development, such as code generators, are more likely to be GPLv2’d, but with appropriate exceptions to allow unrestricted use of the resulting output. We prefer GPLv2 over GPLv3 as we don’t support the anti-Tivoization clauses.'}
- p {'Commercial use of my code is freely licensed because I believe the days of shrink-wrapped software are over, and it’s essentially the customization process that provides the value. So please go ahead and incorporate the code, and should you require customization or in-depth consulting for your application later on, then I can do so for an appropriate fee. Usually this is on a non-exclusive basis, so that if I add features on your behalf, I can also release them generally.'}
+ p {'We do not charge individual licensing fees for use of the software. We prefer that you use the software unrestricted, and promote its use within and outside your organization. This policy allows us to benefit from consulting fees if you require further development or customization, usually on a non-exclusive basis so that all users can make use of any improvements. Our fees are very reasonable and we encourage you to make contact if you have any requirements.'}
- h4 {'About my coding style'}
+ h4 {'About our coding style'}
- p {'I like precision and I generally don’t leave unhandled cases in my logic, unless they are clearly flagged by assertions and such like. (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.'}
+ p {'We emphasize precision and we generally don’t leave unhandled cases in our logic, unless they are clearly flagged by assertions and such like. (In a long career as a professional programmer, one encounters Murphy’s Law on a regular basis). We also prefer consistency in matters such as identifier naming, indenting and so on.'}
- 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. This lets me get up and running quickly with a basic feature set (and pass trivial test cases almost immediately). In the longer term I rely on people like yourself to download and exercise my code and inform me of the features you’ll use.'}
+ p {'Having said that, our emphasis is on productivity rather than dotting i’s and crossing t’s. So the code can be rough until we decide to polish it up for release. As an example, we would implement a language compiler with nearly all language features as stubs that crash the compiler with an assertion message. This allows us to get up and running and handling trivial test cases almost immediately. A feedback process then tells us which further language features are needed. Esoteric features are never added, since those assertion messages are not triggered. We rely on your input in such cases.'}
- 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.'}
+ p {'Commenting in the code is sparse at best. This is because our emphasis is on refactoring the code until it solves a problem appropriately, according to our evolving understanding of the problem. To spend inordinate effort writing up the interfaces and algorithms used in the code is a waste of time when the code is experimental. And once it has stabilized there is rarely a reason to revisit it, unless we’re adding documentation comments for the API reference.'}
- 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!'}
+ p {
+ 'Because we use few comments (only in cases where the logic relies on subtleties that won’t be obvious later), we tend to write code that is self-documenting. This means writing out longer code for operations that can be accomplished with language tricks ('
+ tt {'p != NULL'}
+ ' rather than '
+ tt {'!p'}
+ '), and avoiding abbreviations in most places. Of course if we find we cannot understand our code later, we will comment it once we have figured it out again!'
+ }
- h4 {'About my testing style'}
+ h4 {'About our testing style'}
p {
- 'On this point I refer the reader to an excellent article, ‘'
+ 'We refer the reader to an excellent article, ‘'
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'}
- '’. I do in fact use tests, and they are often to be found in a '
+ '’. We do in fact use tests, and they are often to be found in a '
tt {'/test'}
' or '
tt {'/tests'}
- ' 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.'
+ ' directory in our repositories, but the tests are only what we needed during development to exercise the code, and they might not be maintained once we are satisfied that the code works.'
}
- 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.'}
-
- 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.'}
+ p {'The problem with unit tests that are required to be maintained (usually as a matter of company policy) is similar to the issue with extensive code commenting: You end up investing too much into the current way the code works, making it difficult to change it when you see a better way. Thus tests should be kept more general (End-to-End or E2E testing is best) and used as a means to an end rather than an end in themselves.'}
h4 {'Why these projects?'}
- 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).'}
+ p {'The project members are established professional programmers who have spent their lives working in salaried work or for clients. And in this environment, we have to fit into established practices. This usually means unneeded complexity (for example, the use of many middleware layers just to achieve a simple task) and wasted time dealing with internal processes (code review, unit testing and the like). In our free time, we are free to seek a better way.'}
- 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.'}
+ p {'The NDCODE project aims to challenge established practices in the areas we touch. The goal is to find new ways of doing things that improve efficiency, as measured by how much we can achieve or build in a limited time. By making a frank assessment of what works and what doesn’t work, both in the existing method and in our experimental new methods, we are able to find a synergy, but paradigms are not upended overnight, and the process takes tedious experimentation.'}
p {
- 'I would aim for a sort of a happy medium where I use established tools such as '
+ 'We tend to use established tools such as '
tt {'Linux'}
', '
tt {'Python'}
', '
tt {'node.js'}
- ', 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 '
- tt {'docker'}
+ ', and the extensive infrastructure that comes along with them, as a platform for our experiments. Whilst these tools are far from perfect, they provide significant power for rapidly prototyping solutions to problems. However, we try not to add a lot of middleware layers like '
+ tt {'Docker'}
', '
- tt {'mysql'}
+ tt {'MySQL'}
', '
tt {'nginx'}
- ', and the like. I like building on the bare metal where I can.'
+ ', and the like. Not only do they add complexity, but they work in very prescribed ways and the rest of a system tends to become designed around them. Thus, complexity gets ossified and rusted on over time.'
}
p {
- '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:'
+ 'Some of the specific projects on this site are:'
ul {
li {
- 'The JST project allows to build websites efficiently.'
+ 'The JST project—allows to build websites efficiently.'
}
li {
'The '
span.serif {'π'}
- 'tree project allows to build languages efficiently.'
+ 'tree project—allows to build languages efficiently.'
}
li {
- 'The LogJSON project allows to build databases efficiently.'
+ 'The LogJSON project—allows to build databases efficiently.'
}
}
+ 'In keeping with our mission, these projects are rather lean compared with competing offerings such as, say, '
+ tt {'Django'}
+ ', '
+ tt {'ANTLR'}
+ ', '
+ tt {'MySQL'}
+ '. Whilst we have nothing against the competing tools, and they may be a good fit for certain applications, they may also be more complex, more fragile and/or have a steeper learning curve. Our philosophy is ‘less is more’.'
}
p {
- 'There are also some associated Computer Aided Software Engineering (CASE) tools that I built as examples, such as the '
+ 'There are also some associated Computer Aided Software Engineering (CASE) tools that we built as examples, such as the '
tt {'c_to_python'}
' tool which (roughly) translates C code into Python using the '
span.serif {'π'}
- '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.'
+ 'tree framework. Having custom-built CASE tools can really turbocharge a refactoring project and make the impossible possible. CASE tools can also make it possible to develop larger and more ambitious projects efficiently.'
}
},
// scripts
public / ndcode_site.git / commitdiff