Released Episode 2, discussion: Testing with Mike Evans

[artem-zinnatullin]

🚀

Show notes https://github.com/artem-zinnatullin/TheContext-Podcast/blob/master/show_notes/Episode_2.md

[emartynov]

Thanks!

[artem-zinnatullin]

Wanted to apologize to @MichaelEvans and listeners for not letting Mike talk enough, some listeners noticed that and I completely agree, it's totally my fault, I'm very sorry for that 😞

Podcasting is not that easy as I wanted it to be, unfortunately 😿

If you'll notice such things in future — please give me a feedback, it's very important!

And thanks @MichaelEvans again for being on the show, hope we'll record another episode in future and will do it better!

// Anyway, hope this episode was a little bit helpful for somebody!

[athkalia]

I would suggest that you keep your episodes about 30-40 mins long. If they are longer than that then split them in 2 parts.

[artem-zinnatullin]

Yup, I think I'll split long episodes, it'll also allow me to do sound editing and release a little bit faster. Thanks for feedback!

[Wrywulf]

At some point you mentioned an alternative (trick) to adding a separate "fast build" flavor containing minSdkVersion 21 to cope with long build times for multidex-enabled apps. I've googled and searched the show notes but couldn't find anything describing this.

Can you provide that in the show notes?

[artem-zinnatullin]

@Wrywulf I definitely saw a post about that but I can't find it… I'll write a short blog post and comment here!

[artem-zinnatullin]

@Wrywulf here you go: minSdkVersion for multiDex on developer's machine without additional flavors http://artemzin.com/blog/minsdk-without-flavors/

[vanniktech]

@artem-zinnatullin I also remember that I saw this once in an article. Do you mean this one? It was posted on reddit.

[artem-zinnatullin]

@vanniktech oh nice! It even has a way to pass it in the Run Configuration, thanks! Will add to the post.

[Wrywulf]

Awesome, thanks!

[sebaslogen]

On the BDD topic, in all the projects that I've seen BDD, the goal was not to have product owner or manual testers writing tests but rather reading them.
Product owner or business provides the acceptance criteria for a user story/feature and testers/QA check that the deliveries include a BDD test that matches what they expect.
Then is the task of the code reviewers to make sure the code implementing a BDD scenario does exactly what the BDD English sentence says and I'm still surprised that a lot of times it doesn't correctly match.
I imagine without BDD developers write tests that are even further from what the business requested and closer to ensure that the written code works according to what the developer thinks and not necessarily what the business wants.

[ewoks]

I need to say it.. I have this feeling from the first episode :( Sometimes it is really painful to listen. Topics are really interesting but there are several things that make me just want to stop listening and never come back:

• as somebody mentioned you barely let your guests talk and express themselves. You have strong opinion about almost everything and you either need to correct or give contra argument for most of the guest opinions. That make guest not wont to talk about their ideas or point of view. Unfortunately I am like that as well and it is difficult to notice in everyday but listening to podcast made me pay much more attention to how I behave in similar situations during day.
• a bit messy explanation of instrumentation, functional tests meaning, when you mixed and shake things. I know what are they but after this episode my face was puzzled. Terminology like this should not be be interpreted ambiguously but according to definitions or common agreement among experts (in this case developers)
• man your microphone is terrible!!! Please change it for any that is better quality. You do not need to spend a fortune but this sounds like cheap laptop integrated mic. Your guest is sometime 5x louder and clear. If I increase volume to hear you normally, when your guest say something it blows my ear. If I adjust volume so guest speaks normally, you sound like whisper.
• limit episodes to 25-40 minutes, if interview is longer divide it in more episodes.
• I find it good idea to publish mp3s on GitHub but somewhat confusing that there are "Source code (zip)" and "Source code (tar.gz)" which has nothing to do with source code

Sorry if this sound too harsh, this is not my goal and it should not discourage you to continue making podcast. Hopefully you will continue and get better and better with each new episode ;) Cheers

[artem-zinnatullin]

@ewoks yeah, my feelings are pretty much the same…

All points are correct: trying to control myself better, bought new microphone, 3rd episode will be released as 2 parts.

Regarding to mp3 files, I'd suggest to use some podcast player app, Pocket Casts is my favorite, maybe you'll find some that will be good for you.

Sorry if this sound too harsh

No problems, I really appreciate fair feedback like this, even though it does not make me feel good, but it's fair.

Can you please listen first part of 3rd episode and give feedback?

[ewoks]

No worries, we are here to give constructive critic but to support as well. I was feeling a bit bad after writing yesterday so but hopefully it will push you forward :) Starting with 3rd episode tomorrow and looking forward to it

[netimen]

Thanks for the podcast!

What about TestNG: have you tried it, is it worth trying?
And what do you think about mockists vs classicists testing styles?

[dimsuz]

I had exactly the same feelings as @ewoks after listening to this episode, by the end I didn't like it at all, but all in all I learned something useful out of it, so thanks to you and Mike. It's good that a) @ewoks summed up issues nicely (even if harsh) b) you listen and is open to such kind of feedback.

I am currently listening to the Part1 of episode about RxJava and I must say I am enjoying it very much this time: you certainly improved on all of those points, thanks! Keep it up then! :)

[dimsuz]

It's actually interesting to find out about different opinions on a variety of discussed subjects, i.e. it's interesting to hear each opinion backed up by some explanation on why it feels right/not_right for someone, and on the other hand it feels like wasted time when the listeners have to listen to some kind of enforcing of certain opinion.

For example, Part1 of RxJava contains explanations of some things looked up from different angles, expressed by you and your guest - and this is really interesting! You describe why you think this way, he describes why he thinks that way, you both say "ah, ok" and respect each one's opinion, and there's no sense of conflict or enforcement of some direction - everybody wins! :)

[artem-zinnatullin]

Thank you for the feedback! Yeah, I'm not proud of 2nd episode and I'm
really sorry for Mike because of that, but it is what it is..

Great that you've noticed that in this podcast people have different
opinions, one of the points of why I decided to start it because other
podcasts about Android Development are not so diverse in terms of
discussions.

Hope to read your feedback about 4th episode about Indie Development,
podcast has changed pretty much!

On Wed, 11 May 2016, 02:00 dimsuz, notifications@github.com wrote:

It's actually interesting to find out about different opinions on a
variety of discussed subjects, i.e. it's interesting to hear each opinion
backed up by some explanation on why it feels right/not_right for someone,
and on the other hand it feels like wasted time when the listeners have to
listen to some kind of enforcing of certain opinion.

For example, Part1 of RxJava contains explanations of some things looked
up from different angles, expressed by you and your guest - and this is
really interesting! You describe why you think this way, he describes why
he thinks that way, you both say "ah, ok" and respect each one's opinion,
and there's no sense of conflict or enforcement of some direction -
everybody wins! :)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#17 (comment)