So, when someone says [during the interview] + -I know TDD! +I ask: + -So tell me the difference between Chicago and London style.
+This happened to be The Great Filter, as many people didn't know that. Luckily this wasn't my interview as I didn't know either. So, naturally, I did some googling. + +It turns out, that it's not rocket science at all. +Let's say we're testing the metods talking with DB (using some injectable context, of course) +Chicago style focuses on results. So here you check, if result that you get back is the same as expected. +London style focuses on behavior. So here you mock the context and then validate if methods you need to call were called defined number of times. +Chicago style focuses on results. London style focuses on behavior.+So, it's easy, right? Also - you can also mock in Chicago style, and by getting the results you want test behavior, right? And why is it that important? + +I'll start with second question. If you start mocking around and check for results, your setup/arrange parts tend to grow and be more and more complicated. Also, if you want to test results, you have to provide some sensible data. This makes testing more cumbersome than needed and results in greater reluctancy in writing them. In my opinion those kind of tests work best with integration/end-to-end tests and also with unit testing, were you have no "complex" (or maybe any?) side effects. Pure functions are great example - for same input, always same output, without any side effects. It's very easy to write those tests and arrange part will be small, if almost not existent. + +When you verify behavior, you don't care about carefully setting up mock, populating data, thinking about complex relations. You just want to know that system behaves in a way yout want it to behave. Databases, messaging systems, IO operations etc are fine places. You have other kinds of tests to check if your system is working correctly with those alive elements. Here you want to check if you handle them correctly. + +It's easy, yeah. Don't seem that important. But it's really easy to forget London style and check for result everywhere. Writing tests starts to be painful, they take more time and, out of nowhere, you're dug under pile of complexity. +"But I did unit testing, why is this happening?!" +Because maybe there's more to writing tests than just Assert.AreEqual(expected, actual) ;) + + + +PS: Both ways are equally important and have their own purpose. Don't just focus only on one and you should be fine. \ No newline at end of file diff --git a/_posts/2017-03-17-introduction-to-integration.md b/_posts/2017-03-17-introduction-to-integration.md new file mode 100644 index 0000000..d4ff679 --- /dev/null +++ b/_posts/2017-03-17-introduction-to-integration.md @@ -0,0 +1,32 @@ +--- +ID: 58 +post_title: Introduction to integration +author: dreat +post_excerpt: "" +layout: post +permalink: > + http://dreat.info/2017/03/17/introduction-to-integration/ +published: true +post_date: 2017-03-17 07:00:26 +--- +I started to get more into integration and integration patterns. There are few reasons: +
This is Today I Learned - some nice things I learned, too short to be valid blog post, but too important/interesting/etc to not be written down
+While exposing classes to WCF service, you have to use [DataContract] (for class) and [DataMember] (for properties) attributes. Or do you? + +Turns out that around 3.5 you don't have to do it. If you provide class with no attributes it will work out of the box! Where's the catch? There are two: + What a place to take a break![/caption]
+
+
+
+Sadly, there were no recordings, but from what I saw speakers had the same talks as in some future (and maybe past?) events, so not all is lost.
+"You have to accept that things go wrong it you want to build fault-tolerant systems" - Robert+
Prepare your system: Split it into services first, or at least one monolith service and one small (it's a good start).+
++Always timeout!
+
I've covered 5 out of 9 talks, so there's still material for next part, stay tuned!
\ No newline at end of file diff --git a/_posts/2017-04-23-opensettlers4.md b/_posts/2017-04-23-opensettlers4.md new file mode 100644 index 0000000..7cfcdb8 --- /dev/null +++ b/_posts/2017-04-23-opensettlers4.md @@ -0,0 +1,18 @@ +--- +ID: 110 +post_title: 'OpenSettlers#4' +author: dreat +post_excerpt: "" +layout: post +permalink: > + http://dreat.info/2017/04/23/opensettlers4/ +published: true +post_date: 2017-04-23 21:35:21 +--- +As always - commit! + +I really need to spend more time. Today I struggled a lot with bitstrings. And still didn't find an answer for what I was looking for, but I created a map for command without redundant info. So no more flags, only command name, data and size. + +After push thou I saw a better solution - I could do pattern match on functions, so I could eliminate switch. I get a lot of mess with all those maps. I think that rethinking/refactoring it should happen sooner than I initially thought. + +Also "size" field seems a bit off. Additionally I don't feel as comfortable enough with specification as I was expecting, so I guess I'll spend some more time with it - this should also get me up to speed. \ No newline at end of file diff --git a/_posts/2017-04-30-erlang-factory-lite-rome-2017-1.md b/_posts/2017-04-30-erlang-factory-lite-rome-2017-1.md new file mode 100644 index 0000000..a381b63 --- /dev/null +++ b/_posts/2017-04-30-erlang-factory-lite-rome-2017-1.md @@ -0,0 +1,66 @@ +--- +ID: 113 +post_title: 'Erlang Factory Lite Rome 2017 #1' +author: dreat +post_excerpt: "" +layout: post +permalink: > + http://dreat.info/2017/04/30/erlang-factory-lite-rome-2017-1/ +published: true +post_date: 2017-04-30 22:36:46 +--- +Hello for the second (and last) part of EFL Rome2017 post! You can find previous one here +
Some combinations for you to pick from[/caption]
+
+[caption id="attachment_117" align="aligncenter" width="300"]
With the Joe himself![/caption]
+
+Joe picked OSC over TCP/UPD with some English to describe it. OSC is a very simple encoding - and it has "simplicity by design", as Joe said, "if you can't create complex data structures, the interface will be simple and easy to understand".
+"if you can't create complex data structures, the interface will be simple and easy to understand"+Which is another way worth remebering. Complicated systems are easy - you just keep adding stuff. Simple systems are difficult to make. + +I think thou - if one thing should be remembered from this talk it's fact, that we should be able to understand the system by looking on the messages going in and out. +
This is the Internet! Be careful not to break it![/caption]
+
+The real show started when he took the router, connected third Rasp and added Asia - it all worked! It was a nice show for the Nerves project to show what you can do with them. Funny thing - the most problems, and the slowest part was HTML+JS frontend where all the arrows where hacked as separate CSS elements - so it crashed when connection number rose. Still, great project and you can look at it on github!
+There's Elixir app with Phoenix fronend opened, showing sensor output. Sensors are connected to raspberry pi. When sensors are dry it will show cactus, when wet it will show water drop. First there's humidity sensor - if we spray it, the second image will change. As it was not dried properly you can see some changes later, as water drops flows down the sensor. Next there's hydration sensor put in the glass of water - first image will change. Below the images are charts with sensors data grouped by hour. + +Finally "warning" button is pressed, and buzzer turns on. "Warning" button is a switch, so pressing it again turns the buzzer off. + ++See you next year! :) \ No newline at end of file