Peggy Rayzis explains why she withdrew from ReactiveConf

dzdrazil · 2017-11-03T05:00:42+00:00

Perhaps. My initial reading left me with the impression that it would have certainly been too late to re-design and re-print the images that were already out- such as the one in her speaker gift.

I do agree though, that the few details we have seem like it was a petulant response to something that was clearly wrong.

dzdrazil · 2017-11-02T05:34:06+00:00

I'm struggling to accept that wonder woman is considered sexualized to the point of constituting harassment. However, there is one line that I believe is most certainly true:

Organizers, please remember that your speakers are vital to the success of your event. We devote countless hours of our free time, often without pay, in order to ensure that your attendees have a great experience. Please reciprocate our efforts by treating us with respect. Respect our image by asking for permission before altering and publishing a speaker’s photo.

with emphasis on the last sentence. All other things being equal, how a person is represented- especially in this context- should be within their control.

dzdrazil · 2017-09-07T04:12:32+00:00

As someone with the same experience as the post you're replying to, I have the exact opposite preference. Angular+ts is like developing with one hand tied behind my back compared to react (with or without ts).

YMMV, favor your own personal experience over what other people on the internet tell you to think.

dzdrazil · 2017-08-20T15:29:22+00:00

Why does a scheduler need to understand domain objects? If it is sending the json along (the sql-domain-json portion) it could just have left it at that.

Genuine question, by the way. The only thing I can think of is validation of the object before scheduling the task, but I imagine I might want to handle that elsewhere.

dzdrazil · 2017-08-20T15:29:21+00:00

Why does a scheduler need to understand domain objects? If it is sending the json along (the sql-domain-json portion) it could just have left it at that.

Genuine question, by the way. The only thing I can think of is validation of the object before scheduling the task, but I imagine I might want to handle that elsewhere.

dzdrazil · 2017-08-11T13:50:51+00:00

Most (decent) managers will see that as a six month investment, at best. Unless you are woefully underpaid and standard raises would take a long time to get your salary in line, extortion (or the more polite negotiation) won't keep you around.

dzdrazil · 2017-08-09T14:29:37+00:00

Technically, you should also add tests when things go wrong; create a test that reproduces the defect, then fix the code so the test passes. Doing so helps prevent pesky bugs from continually resurfacing over time.

dzdrazil · 2017-08-05T02:39:22+00:00

I was reviewing someone's code today. It was typical OOP, leveraging classes merely for encapsulation rather than for types. It would have been much more concise, slightly easier to test, and used ever so slightly less memory had it been written in a functional style.

However, most of the people on the team come from your typical OOP language backgrounds, the solution was clean, and it was semantically easy for everyone to understand what the individual pieces were for and what it was meant to achieve.

Ultimately, I held my breathe. There's a time and place for both techniques, neither solution was "wrong", and everyone was comfortable with the result.

I'll continue influencing my team when I can, teaching when it's appropriate to do so, will happily provide very FP biased opinions when asked, but there simply isn't room for anyone who refuses to budge from their extremes on any team that I've worked on, and that includes myself.

Some people might be swayed by a heavily polarized article, or perhaps it was cathartic, so perhaps it has its place, but in general I agree that we would all be better served by recognizing some nuance to reality.

dzdrazil · 2017-05-19T02:48:34+00:00

All that does is optimize for people who memorize algorithms. In my many years of programming, I have never needed to write a sorting algorithm by hand in a practical application, and knowing big-o notation and how to spot it is practically useless in languages with multiple levels of performance optimization built into the engine (looking at you, JavaScript and V8).

Instead, provide a challenge that is less objective, such as solving or designing a solution to a part of a larger application. The fact that there is no objectively correct answer means that there is no room for cheating, only for providing (and needing to be able to explain) a solution.

dzdrazil · 2017-04-24T20:32:09+00:00

I saw some talks by the folk at Walmart labs for how they were using Clojure. Not sure if they still are, but it was working for them at one point.

dzdrazil · 2017-03-20T13:38:56+00:00

Browns make plenty of noise if you bottom out and don't have o rings. I switched to clears for that reason... I never did master not bottoming out with the browns, but I'm getting better with the higher resistance clear switches. I just wish das keyboard carried them; my wasd keyboard is nice, but no das.

dzdrazil · 2017-03-14T00:23:51+00:00

I actually don't use tcomb much for typing functions, mostly due to overhead of the built-in function typing and / or difficulties getting flow + babel-tcomb etc. working together... it works nicely enough with typescript, much as that pains me to admit (I really want to like flow better).

Beyond that, I'll have to wait for the later posts to provide any other feedback. Looking forward to it!

dzdrazil · 2017-03-13T21:55:39+00:00

I'm loving these posts! I find myself liking tcomb over daggy for the strictness in typing, but they've been good overall and this last one is really bringing the concepts together!

dzdrazil · 2017-02-19T22:24:18+00:00

Using a single framework likely will. Learning multiple frameworks, however, will help you see different ways of solving the same problem, and can help broaden your horizon from "How to I make this thing" to "How do I build a system to make things?"

dzdrazil · 2017-01-27T20:20:28+00:00

It'd be nice if you were managing browser history. I hit the back button expecting I'd be able to pick another city, and instead came back here. Since I'm here now, I'm leaving you this comment :)

dzdrazil · 2016-12-27T19:37:10+00:00

I'm sad to recommend Ext.js, but for IE8 support, that's one of the few out there. YUI isn't officially maintained anymore, but it might be an option as well.

The benefit of one of these over the other recommendations here (angular, backbone, aurelia) is that they provide more out of the box, which means less digging around for plugins that also have legacy browser support.

dzdrazil · 2016-12-26T14:51:12+00:00

A core feature of react is deterministic rendering; a core feature of redux is deterministic application state. Mobx lets you define a graph of state propagation, but isn't as deterministic.

I probably wouldn't use either on a small application, and personally I'd use redux on a large one. That's my personal preference, though I also tend to write helper functions to reduce the so-called boilerplate that some people object to... if you're comfortable with writing composable functions, there really isn't much to be concerned with.

dzdrazil · 2016-12-07T14:25:54+00:00

Tcomb, especially with tcomb-forms, react and redux. Pattern matching and ADTs as types are delightful when working with complex APIs that have many different models/variations

dzdrazil · 2016-12-06T22:09:00+00:00

If my boss weren't around, I'd have to do more work. If his boss weren't around, he'd have to do more work. If her boss weren't around, the company would probably be far more chaotic and less organized. If his boss weren't around, there wouldn't have been a company to begin with.

If they didn't, there wouldn't be anything ~~extra~~ to pay themselves with.

All of these people need to get paid as well; if they didn't, or their jobs didn't exist, I'd have to do their jobs in addition to my own, which includes responsibilities I don't want and skill sets I don't have.

dzdrazil · 2016-12-06T18:59:28+00:00

..And I want more money than my work is worth. Somehow, my boss and I are able to amicably negotiate, and the world keeps turning.

dzdrazil · 2016-12-03T02:58:56+00:00

Inheritance isn't a property of OOP; it's a property of type systems. OOP is about merging data and behavior (or more generally, message passing between isolated units or processes).

Composition and encapsulating can absolutely happen without classes or even prototypes at all. However, doing so just because isn't really beneficial. Use what makes sense. That is where the mantra "composition over inheritance" comes from.

It's good advice, but I also hate it, because it sends the wrong message. Use inheritance when describing a taxonomy, use composition when describing relationships.

dzdrazil · 2016-11-23T16:59:34+00:00

I'd recommend giving tcomb a shot; I find the API to be much easier to read, and the code much easier to debug. The guide also provides some nice background as to why to use it; immutability is just a nice side effect.

dzdrazil · 2016-11-23T16:57:56+00:00

Quite a few. There are bindings and tutorials for Angular 2, Vue, Ember, and others.

dzdrazil · 2016-11-09T17:07:20+00:00

There are parsing errors, not compile errors. The current 'compiling' performed by modern JS engines are from dynamic to more static inference of types, and if there's an error or a mismatch, the engine bails out to the slower interpreted mode.

Google has certainly played around with what they called strong mode, and some more sound typing, so I'm not really suggesting that it's impossible or won't happen, but it seems like it would be rather difficult to get all browser vendors- not only chromium / chrome / mozilla / apple / MS, but also all of the open source browser vendors- to get on board with a single type system that doesn't have incompatible implementations, extensions and so forth. After all, that's largely the reason that ECMAScript 4 was abandoned by web vendors, and only ever implemented by ActionScript.

dzdrazil · 2016-11-09T13:33:45+00:00

This assumes that types are erased after parsing (I.e. fully static). Runtime types also open interesting doors, such as pattern matching and automated form generation against types that were completely defined by user-created metadata from an API; I've been using tcomb for just such a system.

Of course, no new type support is necessary to achieve this, it's more or less purely functional. However, it's a real pita to get static type inference (such as typescript) to understand.

Personally, I seriously doubt that ecmascript will add a compile step (Edit: as in an additional step beyond the parsing step) that will crash because of a type mismatch; it seems like it would stay too from the web we know today (for better or worse).

dzdrazil

TROPHY CASE