qwer

6 ms·

1.
by qwer 8y ago
It's in the blog post, but more were created by the transition than removed. There were less than 10 issues found and none were anything that users were concerned about.
2.
by qwer 8y ago
I just finished something similar: http://caines.ca/blog/2018/12/11/a-javascript-to-typescript-... We opted to keep it strict (no implicit `any`) through the entire transition but only apply it to ts fil
3.
by qwer 8y ago
Sure... I guess you're saying that you can use the typescript compiler just fine as long as you turn off literally the only reason for it? Have you been on a team that adequately managed a list of thousands of warnings, always finding
4.
by qwer 8y ago
> I'm confused how people can advocate TDD and not like static types too seeing as static typing gives you robust automated tests for the minimal cost of adding type annotations every now and then. For me personally as a TDD person,
5.
by qwer 8y ago
I don't know where this misconception started, but you can't just run javascript through a typescript compiler. There is a huge amount of valid javascript that is not valid typescript. Try something like `const testVar = {}; test
6.
A JavaScript to TypeScript Conversion Case Study(caines.ca)
1 points by qwer 8y ago|0 comments
7.
by qwer 8y ago
Well let me first remind you that you're in a javascript thread. OO Pascal is strict enough that you're not going to get the opportunity to see things work when they get types that they didn't expect because the compiler is
8.
by qwer 8y ago
> If your types are wrong your program is wrong That's not necessarily true though is it? If the "1" in the "1 hour ago" message in the header of your reply wasn't the expected type of the writer of the out
9.
by qwer 8y ago
This sounds like an if-it-compiles-it-works argument.
10.
by qwer 8y ago
Well don't lose sight of the goal. The goal is less bugs. Static typing is just for internal quality. Users don't give a rat's ass if your types are correct as long as the program works. Proof: Many wildly and massively s
11.
by qwer 8y ago
Clearly... but then again I won't work at a place with any developers less than 11x.
12.
by qwer 8y ago
> the easily observed phenomenon that some developers are 10x more productive than other developers. How are you measuring? LOC? Semi-colons per hour? story points? If you're measuring in "dollars earned", how do you thin
13.
by qwer 8y ago
I wouldn't have noticed if it hadn't been pointed out but it's definitely a term for a pretty outdated female-only position so I think the point isn't so extreme. I can almost never detect this kind of stuff because it d
14.
by qwer 8y ago
Just slowly go to bed earlier every day. Set your alarm for your go-to-bed time. Read a book if you can't sleep, but not on a bright-screened device. I used to be such a nighthawk that I'd be waking up daily at 7 pm. Getting ol
15.
by qwer 9y ago
In that scenario I bet they're even more effective without the condescending "manager" adding nothing.
16.
by qwer 9y ago
I know this goes against the usual attitude about remote work around here but... That flow-chart at the bottom is hilariously true. I've been a part of remote work as both a manager and an engineer, and this is exactly how it is becau
17.
by qwer 9y ago
I think it's more nuanced than that and one can consistently hold both viewpoints at the same time. You just need to have the experience that a soa-first approach is even worse than the ball of mud.
18.
by qwer 9y ago
It's because this is an article about engineering decision-making, not repo management.
19.
by qwer 9y ago
I think you really did oversimplify it. Writing a piece of code once obviously affects your speed at writing it again.
20.
by qwer 9y ago
I was a CS TA 20 years ago and it was the same. Literally everyone was doing it to some degree. Back then you would hand in printed source code. People would occasionally photocopy someone else's, scratch the name off the title page
21.
by qwer 9y ago
I find physical exercise gets me back out even easier than napping. It took me a while to figure that out, but it's been really helpful.
22.
by qwer 9y ago
Relatively few, but they're everywhere -- Auto-pilot on airplanes. ABS brakes. Self-driving cars. "Releasing early", in the sense of getting these things into the real world as early as possible so they can be iterated on wi
23.
by qwer 9y ago
Come on... The article is clearly written for a general web dev audience (if not, please let me know the more specific audience you've inferred) and starts with this completely unqualified first sentence: > Let’s get straight to the
24.
by qwer 9y ago
This is just another article telling me about what I should do with my web application without asking me anything whatsoever about my web application. Just because you made a bad choice for your situation doesn't necessarily mean ever
25.
by qwer 10y ago
There are more words after that though.
26.
by qwer 10y ago
Anything involving long-lived feature branches especially ones with multiple collaborators, eg git-flow.
27.
by qwer 10y ago
I once wished this were possible too, but in reality it isn't. With n branches there are n! permutations to test. That's a lot of infrastructure to maintain and computing power to spend and you still don't end up with a sing
28.
by qwer 10y ago
First off, I have no motive to be disingenuous. I really don't care how you collaborate on software with your team. Secondly, CI itself is considered a best practice. I don't know how you could expect wikipedia to mark it as any
29.
by qwer 10y ago
Obviously if you can't break it up into smaller pieces, you can't regularly integrate smaller pieces. That's a tautology. With that said, I've been doing this for over ten years and haven't come across that scenari
30.
by qwer 10y ago
Are you questioning the daily part (continuous) or the mainline part (integration)? I'm also interested in your better source. Every book I've read on the subject and the top 4 search results on google say the same thing.

More ›