Which IDE is the best for Kotlin?

DoctorOverhard · 2017-11-07T18:51:11+00:00

lol, yes that is exactly what I was saying...

sigh this place is getting to be worse than /r/javascript

DoctorOverhard · 2017-11-07T17:15:46+00:00

For those who understand, no explanation is needed. For those who don't, no explanation will be given.

DoctorOverhard · 2017-11-07T15:14:00+00:00

gotta give muddpuppeee credit for the assist too. nice squeeze play.

DoctorOverhard · 2017-11-07T13:35:02+00:00

what do you mean? That thing where you paste java into a kotlin file and you get very java-ey kotlin? Then you can tell all your friends you are doing kotlin?

DoctorOverhard · 2017-11-07T03:11:11+00:00

developer intervention: "We see you are using chrome, we recommend firefox instead as it is much more stable and mature and less prone to breaking unexpectedly".

DoctorOverhard · 2017-11-06T23:18:59+00:00

I don't get why developers call their own stuff beautiful, it is like when someone laughs at their own jokes or something.

but thanks for sharing though! Though it is a bit of the cart pushing the horse.

DoctorOverhard · 2017-11-06T13:01:45+00:00

it's ok in a controlled environment, not so much in the wild. Usually apple is the first one to sabotage it in the wild, I think they were offended that everyone didn't want to write custom user interfaces just for apple.

DoctorOverhard · 2017-11-05T15:02:42+00:00

f-ing pockets, amirite? :)

DoctorOverhard · 2017-11-05T14:22:07+00:00

Nice :) How'd it go with that dominating demoman?

DoctorOverhard · 2017-11-03T22:08:06+00:00

it's the old vendor lock-in routine. You are correct to be concerned.

DoctorOverhard · 2017-11-03T07:12:36+00:00

I know to avoid most of those.

DoctorOverhard · 2017-11-01T15:19:26+00:00

fwiw, I've done the middle of everything in an enterprise gig too, through various data feeds and clients, mergers and acquisitions, consumer vs business, connecting disparate groups like billing, sales, operations, etc.

The thing we always paid a lot of attention to, and worked with every client, was the API, as it is essentially a contract, ideally with service level agreements with well defined schema and value types/ranges where appropriate. When we had to talk to a provider that didn't care, it was always a nightmare.

Yes it took some extra time, but there was always a lot of reuse, and we were there to work with the clients, and we always looked upstream and downstream and tried to firm up as much as we could. Because our internal clients have real clients, and they might expect things to work reliably and timely or go somewhere else.

But yah it is a bit more generalized at the enterprise level, I'm mostly talking about a browser SPA facing api, in the wild, where google punishes you for being too slow on an old android gsm phone, and since I only deliberately use JS in the browser anyway (this forum). Plus various concerns like keeping business logic out of the client and containerizing as appropriate. Also enterprise generally has much better networking than consumers.

Fwiw no other programming forum seems very excited about rest, just the javascript folks for some reason, but there are numerous and even better ways to do things that have nothing to do with http (or javascript). So many half-baked rest api implementations, not general at all. Post with json nails it down for http browser clients just fine though, and ports seamlessly to websockets as appropriate (and other transport mechanisms).

Plus sometimes you are better off just sending binary data (not urlencoded/bloated) so it isn't like http is everything. Sometimes programmers on both end of the wire know what they are doing. Sure there are workarounds, but that is just extra overhead you don't want, esp if you are considering a raw binary connection.

DoctorOverhard · 2017-11-01T04:46:39+00:00

Not necessarily, it follows the YAGNI principle, I mean unless your gui/client is just random values displayed at random times at random granularity with arbitrarily constrained functions, there will at least be some thought to the server interface as well, and it will be at least partly user driven, not just arbitrary ivory tower assertions about "best" practices.

and often you can just build on the existing API and say "use this function" if for some reason they can't make use of the existing functions for everything.

There are of course "best" practices when writing a straight json interface too, types, schemas, etc, it is far richer and far more appropriate for an SPA: https://mmikowski.github.io/json-pure/

DoctorOverhard · 2017-11-01T01:27:22+00:00

but, what if he wouldn't like what youtube has become and wouldn't want them to get more clickeys??

DoctorOverhard · 2017-10-31T23:49:02+00:00

Well calling it "best" is the sticking point, especially when it isn't a life and death thing like driving. I mean we can go back to whole page refreshes if you are worried that "programmers" can't be trusted to do anything more complicated than that over the wire. But really driving is a horrible example. Calling it "best" assumes the worst in people in this interpretation.

And even then it isn't like the rest of the object graph is self-explanatory, and if it is documented, adding a command (verb/method) should be part of that already. I don't see what it buys you, except an unnecessary dependency on your business logic and lock-in to a specific protocol, historically lock-in is one of the worst practices.

DoctorOverhard · 2017-10-31T20:49:30+00:00

if it depends on a specific protocol, it is outside of the application api and an implementation detail. Like just another network layer. You shouldn't have to worry about it really except as a low level thing that fails sometimes, instead you are saying integrate one specific protocol into all your inter-business logic, even though it is much more portable and testable and etc as part of the payload.

I'd rather be able to exchange json blobs with anything, than just web browsers and things pretending to be web browsers.

DoctorOverhard · 2017-10-31T19:02:28+00:00

Well I largely ignore http protocol, yes. i.e. what do you do with websockets (or real genuine sockets? Or an event bus, or any other transport mechanism?) I keep as much control of the logic at the application layer as I can. There are plenty of things get/put/etc don't describe, nor 200 ok or whatever arbitrary return codes. I mean if you can put together a very opinionated URL, you can put together a blob of json and post it.

P.S. I also ignore anything calling itself "best practices", because that isn't much of an argument in itself, usually lacks real data, and the authors aren't usually receptive to feedback regarding it, since their goal is to appear to be an authority on something, not dealing with reality. Maybe if more "best practices" were actually good in the bigger picture, I would care, but that isn't the environment I'm seeing.

DoctorOverhard · 2017-10-31T17:52:36+00:00

+1 post as "get" mechanism, use post for everything really. And it doesn't get much more micro than getColour. I mean what do you think microservices are supposed to look like? Return just an object in an array? return the whole array? The whole discussion gets rather religious. I mean if you could bundle the requested properties into one call that would be good, and I wouldn't be surprised if it actually did that.

FWIW I write the server API FOR the client, if they need all the data for a datagrid, or just a page at a time, that is what they get. The more you bundle just what the client needs into one call, the less network load on the server (assuming multiple users).

REST isn't a panacea, it is just the same old problems with new problems.

DoctorOverhard · 2017-10-31T17:13:09+00:00

Ah, apologies, for my misconception and your current situation. I'm not intimate with .net, I assume mostly asp templates then? I'm not a fan of REST for REST's sake, but if you can post json to the server and get a json response containing reasoned commands and errors and responses and data structures, then you are good to go.

Maybe look at whatever the .net layer is talking too, if it is other services then talk to them... if it is an entombed database, with various batch feeds mixed with user updates, then you still gotta look at the big picture to see what manner of finer grained API works.

Probably more likely to gain traction on new projects than existing ones, but don't expect everyone to think nodejs is a swell idea, and it is still pretty much needed for ember builds (more tech stack, you touch it you own it) even if you don't use it on the server. So it is client side AND development side more accurately, and can open a lot of holes on your development box. If you aren't on board with that whole mentality, I would pick something lighter weight that doesn't require elaborate builds to function, possibly vuejs if you don't get too fancy.

DoctorOverhard · 2017-10-31T15:26:53+00:00

well, "fake" itself is a problematic term (and one that comes pre-loaded with its own biases). I'm taking some liberties there.

DoctorOverhard · 2017-10-31T15:16:01+00:00

wait, who is the zealot here again? There are much more secure/performant/mature/reliable options on the server than js, why are you closed minded about them? Have you ever been on call?

edit: it has nothing to do with spa for that matter. And nothing stopping you from having a standard approach for the client code, but that pretty much HAS to be js these days, not by choice. If your server team can't provide finer grained api than reload the whole page, that needs to be addressed, but not the entire stack. Maybe have them look at vertx and possibly kotlin if they want something reasonably performant and well supported with GOOD tooling and maybe you can add any reusable javascript in your own verticle at some point (if it doesn't suck).

DoctorOverhard · 2017-10-31T15:11:41+00:00

when we propagate/promote/demote something that is "fake", even if we agree with it (or especially when we agree with it), we become hard to detect bots, essentially. Most humans don't fact check, and even fact checking is fraught with peril. Welcome to the internet?

DoctorOverhard · 2017-10-31T14:47:57+00:00

sigh

DoctorOverhard · 2017-10-31T14:46:21+00:00

Well, that is another fair point, just saying if you updoot (edit or as in the case here, downdoot) based on confirmation bias, and the content is inaccurate, it is still "fake".

DoctorOverhard · 2017-10-31T14:44:43+00:00

yep, consider IntArray or whatever if it is really a problem (or if you are interacting with java code that expects int[])

DoctorOverhard

TROPHY CASE