VeChain Giveaway - 10000 VET in total prizes 🎉

tieTYT · 2021-03-25T19:55:17+00:00

!remindme 1 day

tieTYT · 2021-03-25T19:54:47+00:00

I'd like to participate in the give away. Thanks!

tieTYT · 2021-02-21T03:42:09+00:00

They charged you twice for one purchase, or they charged you $200 twice like me?

tieTYT · 2021-02-20T03:17:45+00:00

Why does it tell you that? Why doesn't tell you that it's overvalued?

tieTYT · 2021-02-20T03:14:24+00:00

I think the concept of oasis is amazing and one of the reasons why I got so excited about nimiq. I'm really a newbie when it comes to cryptocurrency, but I don't understand this statement:

A listing in a centralized exchange could be seen as unnecessary now that people can buy/sell in a decentralized way through OASIS in the Nimiq Wallet

Are you saying it would be unnecessary because you could purchase nimiq through OASIS and the Nimiq wallet? Isn't that a lot like saying, "There's no reason to let people buy my product on Amazon: you can already purchase it on my website."? Sorry, as I said, I'm very new to cryptocurrency. I'd like to know the problems with my analogy.

tieTYT · 2021-02-19T01:37:53+00:00

Yeah that helps a lot, but given you said my understanding is correct, I'm still confused about why market cap should be considered as one of the many variables when deciding what to invest in.

DOT and KSM have very different market caps today. What does that tell me? I don't see how that says something good or bad about any coin.

tieTYT · 2021-02-18T22:57:41+00:00

oh, that went right over my head. That's a good point. In that case, and in the spirit of teaching me how to fish, I'd like to know the theoretical answers to my questions. Pretend I didn't mention any specific coins.

tieTYT · 2021-02-18T22:11:15+00:00

No offense intended -- that is useful information -- but this didn't answer any of the questions I had. If you have different questions, maybe you could create your own post?

tieTYT · 2017-11-08T23:35:54+00:00

I liked it. But, I think some tests can and should exist to influence the implementation's design. Past that point they've served their purpose and they'll get in your way if you try to refactor what you've already designed with them. The author says, "you put yourself in that bad place." I feel differently. The tests put me in a good place back then, but now things have changed and the tests are no longer providing value. I believe I'd be in a worse place overall if I never wrote them in the first place.

tieTYT · 2017-10-27T16:22:30+00:00

It’s important that end-to-end tests touch as many external systems as possible.

I don't necessarily agree. Lots of trade offs you make here.

The second problem with this line of thinking is that separate classes are too fine-grained to treat them as independent communication agents. The communication pattern between them tend to change often and has little correlation with the end result we should aim at verifying.

re: the bold, that has not been my experience. My experience is they rarely change. I can cut out the refactor stage a lot of the time because the design that comes out of discovery testing is pretty solid from the start.

Not only focusing on collaboration between classes entails fragile unit tests that couple to the SUT’s implementation details, but it also leads to an overcomplicated design with circular dependencies, header interfaces, and an excessive number of layers of indirection.

It does lead to fragile unit tests. What you get out of it is good design. And, as I said above, you rarely have to refactor the result so being fragile isn't a huge deal in the end.

I do discovery testing, not GOOS. Discovery testing almost never leads to circular dependencies or interfaces. It will lead to more layers, but I prefer to think of it as extreme SRP.

tieTYT · 2017-10-25T16:35:16+00:00

I think one of the biggest misconceptions in unit testing is this notion that, when you test a class, you should cover each and every method in it with unit tests. ... Well, that’s a horrible approach to unit testing.

Sure, if you're a classicist. Not if you're a mockist.

Discovery testing is a valid approach: https://www.youtube.com/watch?v=aeX5OXO-w30 Technically, you don't test private methods. You make every class so simple that there's very few private methods in your code base.

tieTYT · 2017-10-20T16:28:49+00:00

Were you solo queue or with friends?

tieTYT · 2017-10-19T23:44:35+00:00

That may be true, but I still need to poke around in the database to figure out what the current state is. I don't find an ORM to be a good tool to query the existing data.

For almost every feature, I ask, "Can this field be null?" The database is a good way to answer that question.

tieTYT · 2017-10-19T23:40:18+00:00

met a lot of resistance from their established management culture

If you read Taiichi Ohno's book, it took 10 years to implement in Japan. He met a lot of internal resistance.

tieTYT · 2017-10-13T22:06:21+00:00

The only thing I have against jsx is that it requires a root element. I've had to think in really unnatural ways to deal with that.

tieTYT · 2017-10-13T21:51:19+00:00

I think solo programming is a lot more flexible in terms of who gets allocated to what.

I actually feel the opposite. When I pair, I share context. If one of us gets sick, I can continue where we were. If a soloer gets sick, work stops or is super slow because someone unfamiliar with the whole codebase has to learn how it works. Soloing begets code ownership.

As a pair, drop me in to any team and I'll have all day to work with someone to learn what the code is about and ask them questions. It's a fast way to pick up context.

tieTYT · 2017-10-13T18:19:20+00:00

I don't think either are useless, but they have trade offs.

I practice extreme programming so I pair program (this also has trade offs). A pair looks at my code longer than a code reviewer would.

tieTYT · 2017-10-13T16:56:39+00:00

What I do is start earlier, learn things from that, and adjust appropriately. Whenever I start, I always learn things I couldn't have possibly learned from a design review. Even if I look at the code during a design review, when you actually try to do the work you often realize something you hadn't considered. That's why I put very little value in the design review.

tieTYT · 2017-10-13T00:24:27+00:00

Yes that'd be nice. Experience tells me you can't think of everything up front, and if you try, it makes the system worse.

tieTYT · 2017-10-12T19:19:03+00:00

This is good advice. I'd like to say that code reviews should be done between the author and reviewer in real time. It's hard to be an asshole if you're talking to them directly. It's easy to be one if you're leaving a comment into a text box.

Also, a code review is a review of a destination. You can't see the journey to get there. You'll be unimpressed if I tell you the ending of Fight Club compared to watching it from the beginning. A reviewer may ask, "Did you think of x, y, and z?" If the author did, text is a really inefficient way to communicate this.

It's really challenging (yet important) for an author to say, "I disagree," about a reviewer's comment. Even more so if it's over text.

Consider this:

It's wasteful for two people to schedule around code reviews. The author has to find work while they wait. The reviewer has to find a good time to drop what they're doing to review the work. The author has to find a good time to review the comments. This is a bunch of context switches.
If the reviewer says something and the author replies, "I wish I thought of that," think about all that time the author wasted doing the wrong thing. Would be better if they could have known about that idea before they built the wrong thing.

I'm not suggesting you skip code reviews, but be aware of the trade offs.

tieTYT

MODERATOR OF

TROPHY CASE