diff --git a/content/books/things-i-learnt/_index.md b/content/books/things-i-learnt/_index.md index 12e3399..1b2c827 100644 --- a/content/books/things-i-learnt/_index.md +++ b/content/books/things-i-learnt/_index.md @@ -36,7 +36,6 @@ template = "section-contentless.html" * Project Organization * [Organize Your Code by Data/Type, Not Functionality](project-organization) * [Create Libraries](libraries) - * [The Config File Is Friend](config-file) * Writing code * [Be Ready To Throw Your Code Away](throw-away) * [Future Thinking Is Future Trashing](future-trashing) @@ -51,6 +50,12 @@ template = "section-contentless.html" * [Start Stupid](start-stupid) * [Always Use Timezones With Your Dates](use-timezones) * [Always Use UTF-8 For Your Strings](use-utf8) + * [Optimization Is For Compilers](optimization) + * Making Things Go + * [The Config File Is Friend](config-file) + * [Command Line Options Are Weird, But Helpful](command-line-options) + * [Not Just Function Composition, But Application Composition](application-composition) + * [Even for Application Composition, Start Stupid](app-composition-stupid) * [Logs Are For Events, Not User Interface](log-events) * [Learn To Monitor](monitoring) * Community/Teams diff --git a/content/books/things-i-learnt/app-composition-stupid/index.md b/content/books/things-i-learnt/app-composition-stupid/index.md new file mode 100644 index 0000000..e7edb4e --- /dev/null +++ b/content/books/things-i-learnt/app-composition-stupid/index.md @@ -0,0 +1,30 @@ ++++ +title = "Things I Learnt The Hard Way - Even for Application Composition, Start Stupid" +date = 2019-07-15 + +[taxonomies] +tags = ["en-au", "books", "things i learnt", "composition", "microservices"] ++++ + +Application composition may lead to microservices -- which is good -- but +microservices require some ideas about how applications "talk" between them +over the wire (protocols and such) which you don't need to start with. + + + +Again, because you just want to simplify your work, you can make the +applications use files directly: Have your first application generate two +files and the second application receive the file names from [the command +line](/books/things-i-learnt/command-line-options). There, simple and stupid, +and works. + +You can even make the first application, instead of generating a file, just +send its result on the standard output, and have the second application +receive the data from the standard input -- both of which are managed as +files, anyway. Then, with a bit of magic, you can put everything together +without wasting space. + +Worry about talking over the wire later, when you understand how networks +work. + +{{ chapters(prev_chapter_link="/books/things-i-learnt/application-composition", prev_chapter_title="Not Just Function Composition, But Application Composition", next_chapter_link="/books/things-i-learnt/log-events", next_chapter_title="Logs Are For Events, Not User Interface") }} diff --git a/content/books/things-i-learnt/application-composition/index.md b/content/books/things-i-learnt/application-composition/index.md new file mode 100644 index 0000000..5741b65 --- /dev/null +++ b/content/books/things-i-learnt/application-composition/index.md @@ -0,0 +1,44 @@ ++++ +title = "Things I Learnt The Hard Way - Not Just Function Composition, But Application Composition" +date = 2019-07-15 + +[taxonomies] +tags = ["en-au", "books", "things i learnt", "composition", "applications"] ++++ + +When we were discussing [the magical number +seven](/books/things-i-learnt/magical-number-seven), I mentioned that it made +more sense to actually call the functions in sequence instead of each calling +the next. That's basically a "function composition", one thing you can also do +with your applications. + + + +Unix came with the idea of "applications that do one thing and do it well". +And then you could just pick the output of one application and plug it as +input of another (and then plug the output of the second into a third, and so +on). + +Also, I mentioned that you could use [configuration +files](/books/things-i-learnt/config-file) to do the same processing over +different source elements (based on a configuration, that is) instead of +writing an application that would process both in a single shot. + +One problem with that approach is that you may need _both_ results to actually +produce a usable result (for example, how would you build a list of common +followings of two Twitter users if you don't have both lists?). + +That problem can easily be solved if you write a different application that +just receives both lists and compare them. That would greatly simplify your +general codebase 'cause instead of one massive codebase with lots of moving +pieces, you'd have two small codebases, with less moving pieces. One could +still break the other -- say, if you or someone else changes the result of the +first function -- but you will still get the results of the first without +missing the whole 'cause the second is breaking. + +PS: I reckon it's really hard to create application composition with graphical +applications (why would you ask your user to have _two_ applications open at +the same time to make something work?) but you can extrapolate this for almost +everything else. + +{{ chapters(prev_chapter_link="/books/things-i-learnt/command-line-options", prev_chapter_title="Command Line Options Are Weird, But Helpful", next_chapter_link="/books/things-i-learnt/app-composition-stupid", next_chapter_title="Even for Application Composition, Start Stupid") }} diff --git a/content/books/things-i-learnt/command-line-options/index.md b/content/books/things-i-learnt/command-line-options/index.md new file mode 100644 index 0000000..def1fb0 --- /dev/null +++ b/content/books/things-i-learnt/command-line-options/index.md @@ -0,0 +1,32 @@ ++++ +title = "Things I Learnt The Hard Way - Command Line Options Are Weird, But Helpful" +date = 2019-07-15 + +[taxonomies] +tags = ["en-au", "books", "things i learnt", "configuration", "command line options", "cli"] ++++ + +In this day and age, when everything has a graphical interface, does it still +makes sense to add command line options to your application? In fact, it does. + + + +When I mentioned the configuration file, you may have thought about using +adding a default path for it and using the same file over and over. + +Well, that's not wrong, but what if you want to use a different configuration? +Would you keep moving the original configuration file to another place, moving +your configuration back and keep this back and forth? Keep both versions and +just use a [symbolic link](https://en.wikipedia.org/wiki/Symbolic_link) with +the configuration filename pointing to the one you want? + +Why not add a command line option in which the user can select which +configuration file should be loaded? + +This would make their life _and yours_ easy. + +Also, be aware that, today, there may be libraries to handle command line in +every language, which will help you build a good command line interface, along +with standardizing it to have the same interface as other applications. + +{{ chapters(prev_chapter_link="/books/things-i-learnt/config-file", prev_chapter_title="The Config File Is Friend", next_chapter_link="/books/things-i-learnt/application-composition", next_chapter_title="Not Just Function Composition, But Application Composition") }} diff --git a/content/books/things-i-learnt/config-file/index.md b/content/books/things-i-learnt/config-file/index.md index 3723326..692736a 100644 --- a/content/books/things-i-learnt/config-file/index.md +++ b/content/books/things-i-learnt/config-file/index.md @@ -34,4 +34,22 @@ most of its can be used all the time. If the intersection of used things is very small, it may make more sense to split into different libraries and just "pick and chose" what to use. -{{ chapters(prev_chapter_link="/books/things-i-learnt/libraries", prev_chapter_title="Create Libraries", next_chapter_link="/books/things-i-learnt/throw-away", next_chapter_title="Be Ready To Throw Your Code Away") }} +But besides the replacement of libraries, you can also think things like: "Ok, +I have to remove elements after a while[^1]; but which would be a good time +that they can exist before I can remove them?" Well, if you're not quite sure +(and, sometimes, even when you're sure), you can use a configuration file to +define how long those elements will stay in the system before being expunged. +Maybe you're not even thinking about how long each element will stay in the +system, but how many of those elements you'll keep in the system before +removing the old ones -- which is, again, a good candidate to be moved to a +configuration file. + +Configuration files allow you to change properties of the system without +recompiling everything. And, if in the future you decide to follow the [12 +Factor app](https://en.wikipedia.org/wiki/Twelve-Factor_App_methodology), +you'll find that you're half-way through it. + +[^1]: In other words, they have a [time to + live](https://en.wikipedia.org/wiki/Time_to_live). + +{{ chapters(prev_chapter_link="/books/things-i-learnt/optimization", prev_chapter_title="Optimization Is For Compilers", next_chapter_link="/books/things-i-learnt/command-line-options", next_chapter_title="Command Line Options Are Weird, But Helpful") }} diff --git a/content/books/things-i-learnt/libraries/index.md b/content/books/things-i-learnt/libraries/index.md index 2c4cd2a..ac3a563 100644 --- a/content/books/things-i-learnt/libraries/index.md +++ b/content/books/things-i-learnt/libraries/index.md @@ -45,4 +45,4 @@ your control, they are external to the project. So you may need to learn how to deal with this before creating the libraries. And, unfortunately, each language and build tool has its own way to manage this. -{{ chapters(prev_chapter_link="/books/things-i-learnt/project-organization", prev_chapter_title="Organize Your Code by Data/Type, Not Functionality", next_chapter_link="/books/things-i-learnt/config-file", next_chapter_title="The Config File Is Friend") }} +{{ chapters(prev_chapter_link="/books/things-i-learnt/project-organization", prev_chapter_title="Organize Your Code by Data/Type, Not Functionality", next_chapter_link="/books/things-i-learnt/throw-away", next_chapter_title="Be Ready To Throw Your Code Away") }} diff --git a/content/books/things-i-learnt/log-events/index.md b/content/books/things-i-learnt/log-events/index.md index edeb658..ec8349a 100644 --- a/content/books/things-i-learnt/log-events/index.md +++ b/content/books/things-i-learnt/log-events/index.md @@ -43,4 +43,4 @@ could have the values to try to figure out why it failed -- surely, logging why it failed also helps, but you know what I mean. This is an example of something that makes complete sense in logs, but not in user interfaces. -{{ chapters(prev_chapter_link="/books/things-i-learnt/use-utf8", prev_chapter_title="Always Use UTF-8 For Your Strings", next_chapter_link="/books/things-i-learnt/monitoring", next_chapter_title=Learn To Monitor"") }} +{{ chapters(prev_chapter_link="/books/things-i-learnt/app-composition-stupid", prev_chapter_title="Even for Application Composition, Start Stupid", next_chapter_link="/books/things-i-learnt/monitoring", next_chapter_title=Learn To Monitor"") }} diff --git a/content/books/things-i-learnt/optimization/index.md b/content/books/things-i-learnt/optimization/index.md new file mode 100644 index 0000000..333e36a --- /dev/null +++ b/content/books/things-i-learnt/optimization/index.md @@ -0,0 +1,39 @@ ++++ +title = "Things I Learnt The Hard Way - Optimization Is For Compilers" +date = 2019-07-15 + +[taxonomies] +tags = ["en-au", "books", "things i learnt", "optimization"] ++++ + +Let say you need more performance on your application. You may be tempted to +look at your code and think "How can I keep this same logic and still remove a +few cycles, so things seem to go faster?" Well, if you want performance, you +need to change your logic. + + + +But before jumping into the code, you may have to check your compiler options. +Maybe you're not generating the optimized version. Maybe there is an option +that you don't use that you can remove from the compilation. + +'Cause "optimization" is what a compiler is for. They _know_ where they can +extract most of the underlying architecture, and people have been finding ways +to make the compiled code more performance for decades. Heck, compilers can +even _delete_ parts of your code 'cause they can "see" that a piece of code +will always produce the same result and, thus, isn't necessary and they will +just put the same result where that piece of code was. + +What you need to do is to think about a better _design_ for your code, not how +to improve the current code. And trying to trick the compiler by [messing with +the types](/books/things-i-learnt/data-types), although may produce faster +code, will really screw you in the future -- specially cause maintenance and +code understanding will take long and figuring out what went wrong will always +be harder. + +Code is written for humans to read. _ALWAYS_. Optimization is what compilers +do. So find a smarter way to explain what you're trying to do instead of using +shorter words or messing with that your code is saying. + +{{ chapters(prev_chapter_link="/books/things-i-learnt/use-utf8", prev_chapter_title="Always Use UTF-8 For Your Strings", next_chapter_link="/books/things-i-learnt/config-file", next_chapter_title="The Config File Is Friend") }} + diff --git a/content/books/things-i-learnt/use-utf8/index.md b/content/books/things-i-learnt/use-utf8/index.md index 2534afe..3c7e33d 100644 --- a/content/books/things-i-learnt/use-utf8/index.md +++ b/content/books/things-i-learnt/use-utf8/index.md @@ -52,4 +52,4 @@ single character. Walking through the whole string would require traversing the string character by character, instead of simply jumping straight to the proper position. But that's a price worth paying, in the long run. -{{ chapters(prev_chapter_link="/books/things-i-learnt/use-timezones", prev_chapter_title="Always Use Timezones With Your Dates", next_chapter_link="/books/things-i-learnt/log-events", next_chapter_title="Logs Are For Events, Not User Interface") }} +{{ chapters(prev_chapter_link="/books/things-i-learnt/use-timezones", prev_chapter_title="Always Use Timezones With Your Dates", next_chapter_link="/books/things-i-learnt/optimization", next_chapter_title="Optimization Is For Compilers") }}