9 changed files with 173 additions and 5 deletions
@ -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. |
||||
|
||||
<!-- more --> |
||||
|
||||
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") }} |
||||
@ -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. |
||||
|
||||
<!-- more --> |
||||
|
||||
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") }} |
||||
@ -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. |
||||
|
||||
<!-- more --> |
||||
|
||||
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") }} |
||||
@ -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. |
||||
|
||||
<!-- more --> |
||||
|
||||
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") }} |
||||
|
||||
Loading…
Reference in new issue