my company just sent out an email saying everyone must uninstall Java due to the license changes in 2019

Only the new Oracle JDK 11, or all versions of Java?

just “Java”

I would assume they want us to move off of Java 8 since it’s being EOL’d for corporations in January

Wow that's big

@lilactown I’ve never used JSX—am I wrong in assuming that it’s a templating language rather than a data structure? For example, I have Hiccup stored in a database (parsed from scientific articles, originally XML). Before serving the Hiccup as HTML, I map over the structure, looking for nodes that have a certain class attached to them. Depending on live data, I transform the nodes holding those classes in various ways. Is stuff like this straightforward to do in JSX?

JSX is a macro for function calls

so you couldn’t store it in a DB (probably)

you can traverse the returned React element tree. that’s how e.g. apollo-react and Relay do data fetching while server-side rendering

it’s definitely easier to do when using native collections, especially in Clojure

Yeah, react elements aren't base data structures like vectors and maps, but they are still data

https://reactjs.org/docs/react-without-jsx.html

just not data in the unordained useful form

there is not much stopping you from replacing jsx with some map-based syntax right. You indeed would need to write a macro to generate createElement calls again

Then you can traverse that map, change it and then expand the macro

both hiccup and JSX are kind of local maximums for their respective users, it seems

native JS data structures feel awkward to write deeply nested structures

all those commas!

yeah you get createElement in createElement in …

plus the UIs they’re usually building are already going to be represented by XML anyway

there are all sorts of libraries out there that implement hiccup for React

yeah right, and those hiccup “trees” you can transform in your clojure right

so then you are where you wanted to be?

yeah there’s tradeoffs with hiccup vs a macro like JSX

hiccup is, at runtime, a vector

which means that you can transform it with your normal clojure.core collection functions

whereas JSX, being a macro that expands to function calls, requires you to operate on React elements which is obviously awkward

you do get some more performance out of the macro approach. but that hasn’t seemed to have much impact for people who use hiccup with rum and reagent

how is that different than having some form of hiccup-to-react macro that you feed a normal collection. The only downside I see is that it is out of your control as soon as you transform it to react

but also React users don’t seem to be clamoring for a way to arbitrarily transform element trees ¯\(ツ)/¯

right, it means you can only operate on it at macro expansion time

right, we are on the same page then ^^

which, again, in Clojure isn’t untenable but in JS-land is completely off the table for most devs

So, let’s say I’m in JS/React vanilla land, and I want to fetch a description of a page that I don’t control at programming time, transform it, and render it (or render it and then transform it, if the former is hard to do in JS). How would I do that?

you would probably build, essentially, an interpreter

So, have the server spit out HTML, then parse the HTML?

can’t imagine that not having been done before

I think the status quo would probably be something like markdown

Markdown is not sophisticated enough for scientific articles. You have MathML and stuff in them.

@henrik well, you’d have the server spit out some data structure. it could be XML. and then parse that to React elements

it depends on if you’re hand authoring them

Alright, so it might as well be EDN made into JSON on the fly then.

ohh its plain old javascript handling it on the client?

rigght

yeah, it would be your best bet to “interpret” your json and build a component tree

Well, I have a Clojure server and a JS/React consumer on the other side. I’m responsible for the Clojure side, so I can hand out whatever essentially.

I’m not saying that your use case is well served in JS-land @henrik. but it also doesn’t (at the moment!) seem very in demand, either

I don’t think that should be too hard, if you do it depth-first

I guess not. So no one is storing and serving pages with React I suppose.

I think most people use server-side rendering for simple cases

we are actually doing that at work, yes, but we had to build that interpretation of JSON => React element tree

Yeah, I can do a lot of necessary transformations while it’s still EDN on the server side. But some things have to be done client side, such as hook up functions to certain nodes, or transform nodes in real time etc. With no guarantee as to what the page is going to look like. You just have classes, IDs, and detecting shapes of data to work with.

we store the pages / page fragments in an external store as JSON

I’m storing transit/msgpacked EDN

that makes sense

our use case is (at the moment) very simple. we don’t have much dynamic UX in those stored fragments

Well, we don’t either 🙂

But it’s going to get more complicated quickly, and JS/React doesn’t seem very good with data transformation.

the main boon is that we have an editorial interface that builds these pages and we can have them hook up to our design library build in React. it’s actually been awhile since I worked on that portion of the system. I had forgotten a lot of this. I see your point that this might be more desirable in the community in the future

At least for cases where you don’t control the page creation directly, but you have to react to someone else’s page.

there’s been a proliferation of design tools library that go from a kind of UI builder => React components / elements. I could see that use case being more important as those tools gain popularity

twitter was going crazy over a tool called Framer a month or so ago

I’m a designer, so I do keep up with the design tools. I’m not convinced that there is substantial benefit in going directly from sketches to code.

That’s not one of the top bottlenecks that design solves.

The top bottleneck is to make management and development understand each other.

I’m actually more convinced that could be a better way for authoring experiences then doing actual design

it’s way cheaper to teach someone to drag some pre-made components around a screen then it is to make a JS dev with React knowledge create the same experience

depending on your business

Yeah, it certainly depends. If you’re making a ton of landing/marketing pages that share virtually the same features, I’d agree.

If you’re working on complex (business-domain-complex) problems the story is different

yep

Either your solution is very specific, and it solves a particular problem really well, or your solution is general, and it doesn’t solve any particular problem, but is maybe good enough in a ton of situations.

we have a healthy collection of both where I work right now. hence trying to use React to standardize our design library

Oh, right. Well, a design system is always nice to default to.

There’s no point in discussing what a dropdown should look like every single time one is needed.

we’re migrating all of our complex experiences to reagent and betting on this JSON => React system we paid some consulting firm to build :face_with_rolling_eyes: for our marketing pages

Oh, interesting!

So then you have an author tool to generate the JSON?

yes, which the consulting firm also built

it depends on the design system to provide the components to show authors when building a new experience

they can then place them and add text, minor theming/styling, etc.

it’s all pretty rudimentary right now but it’s a hopeful solve

of course now, the consulting firm has gone and built a product which does the same thing, after we paid them to build the POC, and are now trying to sell that to us

I’m a bit salty about the whole thing lol

Oh, that’s sneaky.

Aren’t they effectively trying to compete with SquareSpace etc. by doing so though?

Hey fellas , is there any reliable/possible way give a http POST redirect response for an incoming http GET request. I achieve a similar sort of effect by responding to the GET request with a form that auto submits via post method once loaded on the browser. I am not sure if this is necessarily the right way to do it and worried if there are any security implications to this approach. Hope someone has faced a similar task!

That doesn’t sound very RESTful

@zyxmndaleyjes is this a sort of hack to get around some obnoxious client code or are you in control of both the server and client?

only the server

unfortunately I cannot direct talkly to the post endpoint but have to go via the client as it only accepts requests from the client's environment which is a messaging app .

@christian.gonzalez yes 😞

I think the “RESTful” way of doing this would be to respond to the GET with the required parameters for the client to send the POST itself

it’s not as automagic but much more flexible and predictable

I agree, but unfortunately my constraint is that the client code is not changeable and it will send the initial GET request and that's it . Any parameters I send to the client will be ignored, unless I send it a redirect or something that executes automatically like the form auto submit for instance .

What's the best OOP book describing this style of programming/testing? I'm already familiar with it, but would appreciate an authoritative source that I can pass to my peers

(DI is well-known of course... but side-effect-free OOP not so much)

…that is not what dependency injection is

which is not helpful when you’re looking for an authoritative source 😄

I guess you’re looking for things around single responsibility principle and composition over inheritance

> …that is not what dependency injection is Dunno, e.g. stuartsierra/component advertises itself as a DI solution, which makes sense to me. And component eases writing projects that follow the technique described in the screenshot

I meant the quote you pasted; “let’s rewrite this function so it obtains all its state from the caller”.

If an object has no state, why make it an object? This is how you end up with awful Util classes full of statics.

mark seeman had a great video "type driven development in f#" and it was basically how we worked in C# with DI

What is your second favorite programming language? =]

@lady3janepl I took @vemv to be saying they were on a team and/or working in a language that was very OO, and that they were looking for a way to make things a bit more functional*. @vemv did I get that rightish? * without making the team feel too threatened

(in retrospect I was maybe going out on a limb there 😆 )

That's right @eggsyntax, the team's instinct is to just inline side-effects instead of using any kind of DI or argument-passing Now, I don't want to pass them a bunch of blog posts from folks I happen to agree with. I'm pretty sure this has to be a well-known practice in certain circles

I agree with @lady3janepl that when OO folks talk about DI, they're fundamentally talking about objects which bundle state. So if it were me, I wouldn't choose DI as the point of intervention.

pipeline style programming

decorators and such?

@vemv you may want to look into “Constructor-based dependency injection”, if you want some “authority” to refer to check out https://martinfowler.com/articles/injection.html for instance

this is how we programmed at last job in C# and it was quite nice

see, that’s what I know as DI 🙂 object composition.

(of course, when you couple this with the common “define dependencies declaratively”, you can end up with circular dependencies, and also what I heard someone once call “ask for a monkey, get a forest” (ie you ask for a service which requires its 3 dependencies to be instantiated first, which requires their 12 dependencies to be instantiated first, which requires…)

https://img.devrant.com/devrant/rant/r_1115316_Gu43h.jpg

dependency injection for us removed that concern with interfaces. it might be a monkey in a jungle but all you coded against was IMonkey for example

very nice to code against what you needed IMonkey and then later worry only about those requirements in a dedicated class

yeah, the monkey thing is a runtime problem rather than a coding problem

also spec testing with interface based mocks is 👌

if you write Java 8+ with constructor DI, interfaces and without the big, “enterprisy” frameworks, it’s actually not bad

anyway, I think we’ve veered off the question quite far now 🙊

good thing we’re in #off-topic 😉

> https://martinfowler.com/articles/injection.html gave it a quick read, it might be on the right track but the amount/density of boilerplate can be scary. The essence of the pattern is probably small and clean. The other day I created a good-enough component clone in Ruby in dunno, 45 minutes? Also I'm interested in how DI relates to side-effects, which in turn relate to testing. I could find some blog posts illustrating this relationship, but without the clarity and authority that can really motivate a team and make them learn new things fast. Perhaps for what I want to achieve (convey a specific technique/benefits) there's no shortcut 🙂

I noticed that the article is from 2004 so it’s probably not up to date with how people are doing things in 2018

this is really all there is to it: https://softwareengineering.stackexchange.com/questions/177649/what-is-constructor-injection

Is it ethical to just “double your estimates”? I get the idea is to offer padding for the unknown unknowns buuuut is the practice dishonest or at the very least demonstrating a lack of ability on my part to accurately estimate projects?

Is anyone adversely affected by it?

my understanding is that if you don't double it it isn't accurate. seems unethical not to double it

Remember Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Those are excellent points. I don’t think anyone is adversely affected by doubling it and if it’s the hubris of an engineer to believe they can accurately estimate a project then it sounds like it’s the right way to handle it.

When you estimate how long a job will take, you will default to assuming everything will go right. It's been demonstrated often that human beings are not very good at picturing realistically how sub-optimally life turns out. 😄 Double your estimate with a clear conscience, and after doing it a dozen times, see if doubling is enough. https://en.wikipedia.org/wiki/Planning_fallacy https://www.lesswrong.com/posts/CPm5LTwHrvBJCa9h5/planning-fallacy

@jayzawrotny I think it's fine, with the caveat that someone needs to double it at some point along the line. If you have a savvy PM, it may be worth communicating with them about which of you will do that. Although frankly, if you both double it, it often ends up being more accurate 😆

> Double your estimate with a clear conscience, and after doing it a dozen times, see if doubling is enough. ☝️

Good PMs know to multiply any engineer's estimate by pi.

When I was about 25, an engineer I worked with who was about 50 and I talked and decided on the rule of thumb: Multiply the time estimate by (50 divided by the age of the engineer giving the estimate)

Haha

Did that work?

I didn't actually apply it that often. Remember it more for its humor value than anything else. Some managers / VPs who are good, are good in part because they figure out and remove the road blocks that make better time estimation possible.

I find it useful to be aware of the inside-view vs outside-view discrepancy (from Kahneman; see http://www.overcomingbias.com/2007/07/beware-the-insi.html ). We tend to estimate from our inside view. Adding a fudge factor is something we do from outside view, based on our observations over time of the relative (in)accuracy of inside-view estimates.

(the planning fallacy articles posted above probably talk about that)

Firstly, the problem is that estimates are often taken as informal deadlines.

(This is not a deliberate evil or incompetency; this is anchoring effect in action - the same reason for why people say “never be the first person to give a number in negotiations, but if you do have to give a number, start with an overly high one.)

If you start with a large estimate and deliver earlier, people will see you as competent; if you start with a short estimate and have to renegotiate it, people will see you as less competent. People value keeping promises. (But not, apparently, overdelivering.)

Ouch, my ego… but very good point. I’m very guilty of doing that.

We all do, because it describes how human buttons are pushed. The problem is, even being aware of where your deficiencies are doesn’t make you better at avoiding them: the aforementioned Kahneman, currently the authority (although my view of who’s the authority might be skewed, as I’m a popscience reader) on the subject of cognitive errors, expressed frustration that despite years of research he was unable to stop himself from making these errors.

A lot of the human experience is probably post hoc narrative building

So, like, is it unethical? Not any more than knowing that your manager is grumpy before first coffee, and waiting with dumping a problem on their head until they’ve had that coffee. I’d say it’s more in the realm of diplomacy and empathy.

(Empathy because I suck at this, you suck at this, we’re all in this together, and the only thing we can do is to be aware of what buttons we may be pushing by our actions.)

and that, gentlemen and ladies, is where I discover great empathy towards people whose eyes are closing and bundle myself off 😉 gn!

Good night! Thanks for your insight.

@lady3janepl well-said!

I think it would be unethical to deliberately give a wrong estimate to someone who was paying you to give your best estimates. I think it is quite ethical to give a range of "best case, if things go well, average case, if average number of unknown things arise, and longer case, if lots of bad things arise"

and try to list the things you don't know, that you believe would lead to the largest increases in time required.

Cool, I did make that list of unknowns for the first time in this project.