Keyboard shortcuts on MacOS

MacOs does some things right. And some not so much.

Positives:

1. A dedicated (and simple!) shortcut for displaying the configuration of an application. On windows, you generally have to fish for "setting" or "preferences" in the application menu. Not so on MacOS - it is always command+",".
2. A variety of shortcuts for different screenshots.

Negatives:

1. No dedicated keyboard shortcut for find and replace. On Windows, it is always ctrl+"r". On MacOS, it is application specific.  Sometimes it is command+alt+"f", sometimes command+shift+"f" and sometimes there is simply no keyboard shortcut at all and you have to use mouse to tell the app to perform the find and replace and not just find! If you wonder, both, F5 and command+"r" perform refresh.
2. No keyboard shortcut for displaying context menu - you have to use right click on the mouse.

International Software Testing Contest - experience

Why I write about the contest: Since I am one of the winners of the first ISTC competition held in 2017, it is in my best interest to promote this competition in order to make famous.

The assignment description: The contest consisted of writing tests for two Java projects: Naive Bayes classifier and Prim's algorithm for calculation of minimum spanning trees. A copy of the assignment: download.

Strategy: In 2017, we were evaluated only based on the branch coverage (line coverage was ignored contrary to what was written in the invitation) and the mutation score. Only in the case of a tie, the count of test cases would have been taken into the consideration. Since no tie happened in 2017, the recommended strategy for the next years (under the assumption that the rules do not change) is simple: maximize branch coverage even at the expense of the count of test cases.

Furthermore, to maximize the mutation score you have to use asserts in your tests. My strategy was: print the result of the method into a console:
    System.out.println(someMethod());
And use the printed output in the assert:
    assertEquals("textOutput".trim(), someMethod().trim());
I used trim methods because I did not want to deal with the errors caused by wrongly copy-pasting too many/too few whitespace characters. Is it a test strategy I would use outside of the contest? No way, because the toString() format can change anytime. It may not catch all deviations. And not all objects have to implement toString(). But at ISTC 2017 it worked reasonably well.

Idea: Use a generator of unit tests like EvoSuite. However, it is critical to make sure that the generated unit tests work even in the evaluation framework because a single non-compiling unit test will result in zero mutation score. If EvoSuite does not work with the evaluation framework, consider using Randoop, which is possibly less sophisticated than EvoSuite, but generates clean unit tests without any non-standard dependency.

Mutation testing: To measure mutation score you may use PITest. If you use IDEA, a nice plugin providing integration of PITest into IDEA is Zester. Following mutators were used to calculate the mutation score:

1. Return Values Mutator
2. Negate Conditionals Mutator
3. Void Method Call Mutator
4. Conditionals Boundary Mutator
5. Increments Mutator

Warning: The branch coverage and the mutation score that you obtain from your favourite tools may not 100% agree with the scores reported by MoocTest - the tool used to evaluate these two metrics in the competition. Hence, if you can, train yourself against the framework used at the contest.

Another trickery I run into is that JDK7 was required. But because I also had JDK6 and JDK8 installed on my computer, I run into unpleasant clashes during the competition that has cost me 7 minutes of debugging. If you can, have just a single JDK installed on your computer.

Finally, the source codes were in their default packages and that was interfering with PITest (I realized only after the competition that Zester does NOT work if either the source code or the test code is in the default package). Hence, if you design an intricate plan how to win the competition, prepare also a simple fallback plan.

Pragmatic comparison of MySQL and PostgreSQL

The biggest advantage of MySQL is that it is feature lightweight and that it does not closely adhere to SQL standard. Consequently, MySQL has following nice properties:

1. MySQL implements a rather subtle but sufficient subset of functions from SQL. Hence, it is easier to learn MySQL thoroughly than PostgreSQL.
2. When you get stuck with MySQL, you know it must be doable. And after a while you write a query that does what do you want. In PostgreSQL, you just Google for the function. That is not sporty.
3. It is easier to migrate from MySQL to another database than reversely, because almost each relational database implements the bare minimum implemented in MySQL. As old wisdom says: it is always easier to move from worse to better than reversely.
4. Tables in MySQL are treated as a matrices, not as a relations (sets), as dictated by SQL standard. Consequently, rows in a table have fixed order and the order of the columns in a table can be altered. That makes the usage of the table more user friendly.
5. Many of MySQL commands are shorter than PostgreSQL alternatives, although it is frequently at the expense of ability to configure the command. An example is autoincrement column.
6. MySQL is more forgiving to errors in queries.

On the other end, PostgreSQL, which more closely adhere to SQL standard, has following advantages (some of them are likely more related to the habit of thinking thru the impact of a change than adherence to standards):

1. PostgreSQL has much more usable default setting than MySQL. I had to reconfigure MySQL 10 times during the first 6 months of deployment, until MySQL was processing all the beasty queries it had. On the other end, PostgreSQL with the same content, on the same hardware and corresponding load was working to our satisfaction for 2 years. Then it become necessary to increase the memory limit from 64MB RAM to something bigger to work reasonably with 100GBs of data... MySQL is still better in this respect than Oracle or SAS. But PostgreSQL leads in this respect.
2. Error messages in PostgreSQL not only tell you what is wrong, but they also tell you the line where is the error and propose a solution to the problem. PostgreSQL is the nicest database in this respect I have ever worked with. It may look like a minor advantage. And if you just need to run a legacy database, it is. But if you need to develop something new on a database, it makes a heaven from PostgreSQL. Not a hell like SAS.

Comparsion of SAS Enterprise Miner and RapidMiner

Enterprise Miner (EM)
+ Nice interactive visualizations. Whenever you click on a label, the corresponding data in the chart gets highlighted. Still, the plots could support interactive exploration similar to KNIME, where when you highlight a sample in one plot, it gets highlighted in all other plots.
+ Ingenious default settings. You plug the operator and it works. In RapidMiner you have often preprocess the data and fiddle with the settings to get usable result in a reasonable time.
+ You can selectively execute a portion of a flow. While in RapidMiner you can execute only whole flow. The selective execution in EM is a great feature, which accelerates development, because if you make a mistake at the end of the flow, you don't have to recalculate everything from the scratch. Instead of that, EM (by default) recalculates only branches affected by the change. Unfortunately, this feature takes a high toll. While RapidMiner can process data "on the fly", EM has to process data in steps - each operator in the flow has to finish before the subsequent operators can start. Furthermore, in EM you have to have fast and big storage for intermediate calculations.    
- Uninformative error messages. You often have to blindly test many different things until you find the root of the problem.
- It's full of bugs. Not that RapidMiner would be free of bugs. But after a day of bug hunting in RapidMiner you can at least fix it in the source code by yourself. In the case of SAS you either have to be better hacker, then am I, or you have to go through frustrating process of communication with the infamous SAS support.
- EM ecosystem lacks ETL operators - instead of them, you are supposed to use SAS code operator. Personally, I prefer to perform all the transformations in Enterprise Guide. And then I just load the final table(s) into EM.
- EM doesn't know undo command. Instead of undo, you have to confirm each action, since each change is irreversible. This approach goes against the best UI practice to limit amount of modal windows and make each action easily reversible.  
- EM doesn't know save command. Beware of blind confirming of modal windows! It happened to me several time that instead of deleting a single operator whole flow was deleted because I miss-clicked the operator and selected the drawing board instead.
- Setup SAS ecosystem takes some time. Count something around one month.
- Keep SAS ecosystem running takes a lot of energy. Count two days of repairs for each working day.
- Import of data into EM is tedious as you have first define a library and then walk through a long wizard. Count 5 minutes for even the simplest data set. But at least example data sets from SASHELP are fast to load.
- Moving of EM projects from one directory to another is trivial but unintuitive. First, you must make sure that the name of the project directory is the same as the project name. Second, you open moved projects via "New project" and selecting project directory as the destination directory.   
- Metadatabase. So far all it does is that it doubles maintenance time. I am sure there must be some benefit of having metadatabase but so far I do not see it. Hence I strongly suggest everyone to install a standalone version instead of the server version unless you have some good reason to do it otherwise.

RapidMiner (RM)
+ Fully sufficient ecosystem. You can do all ETL within RapidMiner.
+ You can truly visually program in RM since you have loop operators and conditions.
+ You have source codes.
+ The drawing board is editable during the runtime. Hence you can prepare a new experiment while RapidMiner is still performing calculations on the last experiment.
- Every time you have to rerun whole flow even though you want to make just a small refinement.
- It's too easy to setup the flows/operators that they would take eternity to calculate. For comparison, everything in SAS is optimized for big data and you don't get trapped in computational black holes too often.
- You can't stop running node. You can only tell RapidMiner to prevent execution of subsequent nodes. Hence forced application restarts are common.
~ Since each connection between operators in RM fulfills distinct function it's common that you have to wire two operators with more than one connection (for example one connection for training data and second connection for testing data), making the flow look overcrowded. In EM it's always enough to make a single connection between two operators as each connection can transfer any type of data (training, testing, validation...). Hence flows in EM looks tidier.
~ On the other end RM allows grouping of operators into a single operator allowing "divide and conquer" strategy. While absence of operator nesting in EM makes small EM flows easy to understand, bigger flows look messier in EM than in RM.
- SVD and PCA are ridiculously slow and memory consuming in comparison to SAS versions.
- Graphical presentation of hierarchical clustering is just a joke in comparison to output from Orange, KNIME or MATLAB.
- I miss Partial Least Square regression and full Bayes (not just Naive Baves). But you can get them from WEKA plugin.
- ROC plot should show reference line for simpler visual evaluation.

Recenze 50 odstínů šedi

Hned na úvod trochu kritiky. Jedny a ty samé popisy sexu se v 50 odstínech šedi neustále opakují. Tím se stávají natolik nudnými, že jsem nemohl jinak a přeskakoval je. Přitom pasáže o sexu se dají napsat zajímavě. Například v Justýně od Markýze de Sade bylo potěšením je číst - každý akt přinášel novou pikantnost, navíc popsanou unikátními jazykovými prostředky bez použití jediného vulgárního slůvka. Hold, autorka asi neměla příliš barevný sexuální život ani básnické střevo, jinak si tu neduchaplnost nedokáži vysvětlit.

Nicméně, kniha obsahuje přepěkná schémata: v sexu sběhlý muž se vzdá všech svých žen pro svoji vyvolenou, muž se nechá svojí milou převychovávat, muž je neuvěřitelně atraktivní - mocný, pohledný, inteligentní,... A vyvolená je přitom naprosto průměrná. Nu, prostě sen každé ženy, které byly čteny pohádky o Popelce.

Krom toho část knihy je psána jako román v dopisech. A právě v tom autorka exceluje. Britský humor z dopisů čiší a vynáší tím knihu o několik řádů výš.

Můžu tedy s klidným svědomím říct, že kniha je až na nudné popisy sexu vynikající? Tak to rozhodně není. Kniha je poplatná času svého vzniku a přirovnal bych ji dílům Jane Austenové - ve své době neuvěřitelně populární autorka, ale o století později jsou její díla beznadějně zastaralá. A zdá se, že vydavatelé si jsou této podobnosti vědomi. Kniha, navzdory své tloušťce, je prodávána za velmi nízkou cenu, díky velmi levné vazbě, která knihu předurčuje k rychlé konzumaci - přečíst, maximálně třikrát půjčit a navždy utopit v knihovně. 

Recenze knihy Proč muži neposlouchají a ženy neumí číst v mapách

Z kraje uvedu, že pokud jste četli "Muži jsou z Marsu, ženy z Venuše" od Graye Johna, budete se cítit jak doma. Allan Pease totiž také píše o rozdílech mezi muži a ženami a používá velmi podobné argumenty jako Gray, ale doprovází to jinými historkami. Někdy lepšími, někdy horšími.

Co jsem si z knihy odnesl:

1. Historicky muži jsou lovci, ženy matkami. To se projevuje průměrně horší komunikační schopností mužů oproti ženám - zatímco muži neměli při lovu mnoho příležitostí k mluvení, ženy byli doma ve skupině dalších žen a dětí. Konverzace se jim zautomatizovala a tak zvládají najednou konverzovat a vykonávat jinou činnost. Muži to nezvládají a autor to dokládá  výpovědí ženy, která když se na svého muže opravdu naštve, počká, až bude zatloukat hřebíky, a promluví na něj.
   
   Rozdíl se projevuje i v zorném poli. Muži museli rozpoznat zvěř na dálku, a tak mají zúžené zorné pole. Naproti tomu ženy museli neustále dávat pozor na děti, a tak mají lepší periferní vidění. Autor to ilustruje způsobem vyhledávání másla v lednici. Žena se podívá a vidí. Muž skenuje poličku po poličce, dokud ho nenajde. Ženy řidičky také mají nižší procento bočních srážek, než muži.
   
   Muži také mají lepší prostorovou orientaci, protože za lovnou zvěří museli jít třeba i několik dní a nesměli se ztratit. Naproti tomu ženy se starali o děti, a tak ani nemohli chodit příliš daleko od domova a nebyl důvod, aby museli mít dobrou prostorou orientaci. Autor to ilustruje na parkování auta - muži nemají s podélném parkováním problém, ženy ho nesnášejí. Nebo viděli jste někdy řidiče taxíku, ženu? Řidiči taxiků totiž musí mít dobrou prostorovou orientaci, aby dovezli zákazníka co nejrychleji a mohli odvézt dalšího klienta.
   
   Ženy mají mnohem jemnější pokožku než muži, protože muži museli být schopni se brodit houštím za kořistí bez ohledu na drobné tržné rány. Proto se stává, že muž krvácí z nohy a ani o tom neví - když se soustředí na kořist, drobné oděrky necítí.
2. Muž neustále myslí na sex, žena nikoliv. Preference se ale s věkem mění, a zatímco u ženy chtíč s věkem roste (přibližně do 40 let), u mužů chtíč od 14 let klesá. A to vysvětluje, proč starší dámy vyhledávají mladé zajíčky a starší pánové mladé dívky - sexuálním apetitem si vyhovují. 
3. Muži v manželství mají častěji sex, protože ženy v manželství jsou jistější a mohou se tedy snadněji uvolnit a dosahují čtyřikrát snadněji orgasmu, než svobodné ženy. A pravidelně orgasmu dosahující ženy jsou svolnější mít sex

Když jsem začal psát tenhle článek, myslel jsem, že těch poznatků bude víc. Není. Stálo tedy za to, číst tuto knihu? Ano, tahle kniha vás může osvítit. Ale připravte se na typicky Americký roztahovačný výklad, kde je vše sto padesátkrát zopakováno.