Julio Biason
5 years ago
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