|
i dont want node on any computer i use, let alone as part of development
|
#
?
Jan 1, 2019 22:37
|
|
|
|
| # ? Apr 25, 2024 12:33 |
|
|
Shaggar posted:lmao they make a gui for it now for folks like yourself
|
|
#
?
Jan 1, 2019 22:48
|
|
|
why would angular need a cli or any kind of interface at all?
|
|
#
?
Jan 1, 2019 22:51
|
|
|
Shaggar posted:why would angular need a cli or any kind of interface at all? why do you need msbuild?
|
|
#
?
Jan 1, 2019 22:52
|
|
|
maybe dotnet is a better example
|
|
#
?
Jan 1, 2019 22:53
|
|
|
suffix posted:i've been solving the advent of code challenges in both python and rust as a little experiment I started solving the problems with Q but I gave up that idea pretty quick and just went back to python I did everything in python with the exceptions of day 11 which I decided it was pretty fitting to my current Q skills and day 16 which I did part of it in prolog. I also did use pypy a lot this year, which is not a normal thing in my usual python development. I felt the special need for faster feedback on some of the data I was tackling (day 23 springs to my mind). I'm not sure if python is inherently more productive than a language like rust, in my case it just happened to be the language that I'm more used to and I know all the relevant data structures/tricks in the standard library. It's pretty much just muscle memory. I do think python is a "more productive" language than rust/swift if you're messing around writing DSLs, but that's really the only special case I noticed the type system made a significant difference. I even thought about writing a blog post on this topic, but then again I'm not a huge enthusiast of DSLs tbqh
|
|
#
?
Jan 1, 2019 23:19
|
|
|
also this year's AOC made me wish for gotos more times than I want to admit sorry djikstra for I have sinned
|
|
#
?
Jan 1, 2019 23:20
|
|
|
Symbolic Butt posted:I did everything in python with the exceptions of day 11 which I decided it was pretty fitting to my current Q skills and day 16 which I did part of it in prolog. could you post some prolog for day 16? been thinking of trying it in miniKanren
|
|
#
?
Jan 1, 2019 23:29
|
|
|
is there a 'nice' way to do AoC day six? i've been thinking about it for days and i can't think of any better ideas than "make the board real big and ignore anything that touches the board edge", which is not a very elegant solution
|
|
#
?
Jan 2, 2019 00:02
|
|
|
Corla Plankun posted:is there a 'nice' way to do AoC day six? i've been thinking about it for days and i can't think of any better ideas than "make the board real big and ignore anything that touches the board edge", which is not a very elegant solution I just found the nearest marker coordinates to each point around the bounding box and that gave me the set of markers that made infinite regions
|
|
#
?
Jan 2, 2019 00:09
|
|
|
Suppose you make it "really big" and then exclude everything touching the edge. How big does "really big" need to be, in order to give you the right result? It's quite a bit smaller than you initially thought
|
|
#
?
Jan 2, 2019 00:23
|
|
|
ctps: haven't bothered with any aoc but i did get a npm installed and a webgl example running. only took about 2 hours.
|
|
#
?
Jan 2, 2019 01:30
|
|
|
Shaggar posted:why would angular need a cli or any kind of interface at all? Serious answer: project scaffolding, it makes it very easy to set up new apps and scaffold from various templates. So, the developer is not left to deciding how to wire up the whole app, can focus on implementing the business logic. NestJs is one for Node that seems to be gaining some popularity. I think clis like this a great idea in general, certainly makes me feel more productive.
|
|
#
?
Jan 2, 2019 02:05
|
|
|
Cold on a Cob posted:as someone that hasn't touched front end since jquery was the new hotness*, i want to know: is modern front end architecture bikeshedding all the way down? be honest with me pls React, TypeScript (with vscode), Parcel, Prettier. Don't use Redux, it is terrible. loving hell, if you use nothing else from that list use Prettier, make your IDE automatically apply that poo poo every time you hit save, use lint-staged to forcefully apply it to the contents of every commit. The amount of stupid stylistic bikeshedding bullshit it straight up deletes from your day is immense. React has been fotm for the past three years and it owns a whole heck of a lot. If you need a generic-looking UI and you don't have a designer then Semantic UI is quite nice and its React wrapper is also nice.
|
|
#
?
Jan 2, 2019 02:56
|
|
|
My favourite bike shedding is being forced to put all the @covers annotations on all the phpunit "tests" (I'm using the terms test lightly here) even after I pointed out that there are no code coverage reports being generated because the CI pipeline is broken and nobody has bothered to fix it for years.
|
|
#
?
Jan 2, 2019 06:25
|
|
|
worrying about code coverage is a waste of time, and so is unit testing in most cases
|
|
#
?
Jan 2, 2019 06:28
|
|
|
akadajet posted:code is a waste of time
|
|
#
?
Jan 2, 2019 07:36
|
|
|
FormatAmerica posted:Serious answer: project scaffolding instead, try to have sane defaults that are easy to tweak so the default configuration is very succinct, which is a conclusion our friendly frontend devs have finally seem to have latched on to. of course they didn't land on this before having a detour to the land of fallacies called "we'll have no configuration at all!!!", but still
|
|
#
?
Jan 2, 2019 14:19
|
|
|
Sapozhnik posted:React, TypeScript (with vscode), Parcel, Prettier. Don't use Redux, it is terrible. Do you use anything like Redux, or do you just manually wire state/props?
|
|
#
?
Jan 2, 2019 15:02
|
|
|
DaTroof posted:at my old job a few years back, our department needed a manager, and they promoted one of our developers specifically because he was the least useful guy on the team. like, one of the benefits of promoting him was reducing his coding responsibilities. an exec-level guy straight up admitted that poo poo to me *wonders if DaTroof used to work at old job* Yeah, I worked for a bank that had a manager that was promoted for pretty much the same reasons. I left there a fwe years ago, but I recently heard they are pairing all of the in-house dev teams with outsourced team members from India (since the prev outsourcers from Ecuador didn't work out.) So, every team is 50/50 in-house/ourscourced and hoo boy I sure hope those guys are polishing up their resumes.
|
|
#
?
Jan 2, 2019 15:28
|
|
|
Sapozhnik posted:React, TypeScript (with vscode), Parcel, Prettier. Don't use Redux, it is terrible. Ok, I didn't know if it was just terrible programmer me, but yeah, redux seems to make react actively worse in terms of maintainability. Part of me just thinks that I'm getting too old for this poo poo, so I don't even know anymore. akadajet posted:maybe dotnet is a better example Here's my hot take... maybe these frameworks and the lovely cli tools required to just start a project are actually bad.
|
|
#
?
Jan 2, 2019 15:33
|
|
|
Chalks posted:GET /somelist?filter=butt
|
|
#
?
Jan 2, 2019 16:38
|
|
|
I thought react had a state container like redux now?
|
|
#
?
Jan 2, 2019 17:24
|
|
|
uncurable mlady posted:I thought react had a state container like redux now? As I understand it, React essentially is a state container of this kind. A React component has a state property which is only ever modified using discrete setState calls. This strikes me as very similar to the way Redux is intended to work, clearly separating state (which you're not supposed to modify directly) from actions which cause modifications that state. They're very similar beasts, which is why I've found it a little frustrating to get them to cooperate with one another. It could be you're talking about something else though.
|
|
#
?
Jan 2, 2019 17:30
|
|
|
return0 posted:Do you use anything like Redux, or do you just manually wire state/props? I could probably write a more detailed rant about my experiences with Redux, but in summary it - Is very under-specified: Everybody has to invent their own conventions for stuff so nothing built above it interops - Makes your business logic homeless and punts on re-homing it to your choice from a bunch of lovely "middleware" - Makes type-checking needlessly painful - Is a solution in search of a problem If you have a weird matrix of dependencies between disparate GUI components and your application's internal state then the problem isn't the fact that you're not using Redux, the problem is that your application architecture has a poor division of responsibilities (or your functional requirements are insane). Most people who habitually use React tend to create pairs of components like a Widget and a WidgetView. The Widget component will, say, take a repository object that talks to a particular collection within a REST API as a prop, and a widgetId as a prop. It will async fetch a widget into this.state and render a loading placeholder while this is happening, then when the async fetch is complete it will render the WidgetView. WidgetView will take the current state of the widget object as a prop, an onChange function it can call to update its parent's state, an onSave function it can call to save the changes back to the server (which it might call in a button onClick or it might call from a periodic timer), and a status prop whose type is some shared utility along the lines of "interface Status { busy: boolean; error?: Error }" that its parent can use to disable it while the async save is in progress and report errors from the API. The Widget delegates all of its rendering, and the WidgetView has no this.state and doesn't talk to the API. Also, unrelated to this discussion: HOCs are horrible. Use render props instead, they mostly solve the same problems, but the latter is a lot less implicit and a lot nicer to type-check. The tide of opinion in the wider React community appears to be turning in this direction as well. Sapozhnik fucked around with this message at 17:36 on Jan 2, 2019 |
|
#
?
Jan 2, 2019 17:33
|
|
|
Sapozhnik posted:I could probably write a more detailed rant about my experiences with Redux, but in summary it render props are now lame and hooks are the new flavor of the month (even though they are like at an alpha state right now)
|
|
#
?
Jan 2, 2019 18:01
|
|
|
Mahatma Goonsay posted:render props are now lame and hooks are the new flavor of the month (even though they are like at an alpha state right now) basically all of this is in an alpha state, imho
|
|
#
?
Jan 2, 2019 18:14
|
|
|
Sapozhnik posted:Interesting stuff... Cool. I've used React/Redux, but I'm not really a front-end person so don't keep up with the community consensus very well. I guess a role Redux plays which I quite like is the slightly more forceful decoupling of the model from the view such that multiple views can subscribe to a single model (and automatically generates a proxy per view equivalent to your 'Widget' type), and it's not super clear to me how this works in the Widget/WidgetView world. If the Widget React component contains the canonical state, does everything that needs it expect to receive it via props (and if so, do you end up with some mega-controller at the root?).
|
|
#
?
Jan 2, 2019 19:04
|
|
|
React is the most enjoyable UI development experience I've ever had.
|
|
#
?
Jan 2, 2019 19:22
|
|
|
return0 posted:Cool. I've used React/Redux, but I'm not really a front-end person so don't keep up with the community consensus very well. I guess a role Redux plays which I quite like is the slightly more forceful decoupling of the model from the view such that multiple views can subscribe to a single model (and automatically generates a proxy per view equivalent to your 'Widget' type), and it's not super clear to me how this works in the Widget/WidgetView world. If the Widget React component contains the canonical state, does everything that needs it expect to receive it via props (and if so, do you end up with some mega-controller at the root?). There's no universal answer to that. Ideally the canonical state lives somewhere durable like a server, or localStorage. If you have an app where the user is presented with a menu of collections, which in turn present CRUD operations for each collection, then the model above works nicely. If you rely on individual Widgets in a bunch of different places in the app then there's no harm in re-fetching them from the server closer to the usage site as and when you need them; this is even a good thing in a sense, since you don't have to worry about remaining coherent with the single-source-of-truth if your locally cached view of a particular widget is transient rather than long-lived. If you need to render individual Widgets in many different ways then your Widget can take a render prop; literally a prop called "render" which is a function from a viewProps parameter that uses said view properties (the item, a save callback, an async operation status etc, as above) to render WidgetViewA, WidgetViewB, etc. Probably also a renderPlaceholder to, well, render a placeholder while the item is being loaded. If you need to render a complex view (complex in the sense of presenting multiple constituent entities) whose responsibilities cut across multiple collections of entities then you're probably going to need to, in turn, need to do some complex querying from your backend to return a graph of related entities in one call, so you'd have to create specialized Complex and ComplexView components for this use case. ComplexView could possibly compose WidgetView internally, although in that case the onSave callback would probably have to be optional and it wouldn't be a perfect fit. I think a concrete example of what you might be getting at would be, say, Facebook with your currently logged in user profile and its photo, which would be used all over the goddamn place. Many things subscribe to this, but not so many things will publish changes to it. So yeah you'd have some sort of "god controller" high up in your component hierarchy that owns this object and passes it as a prop to the stuff within. If you have several of these entities then yeah you'd probably end up with a stack of these god controllers and it would get messy, but again I'd need an actual concrete example to talk about its design implications. Explicitly passing it through the hierarchy as a prop would be the preferred solution (and it makes writing tests easier, if that's something you care about, which tbh i'm not convinced about with ui code). If you really end up going crazy from drilling boreholes to pass this prop through too many layers of sediment then as a last resort you could use the new-style Context API in React, but it's the React equivalent of global variables, with all the problems that entails. And it's the exact same mechanism that underpins Redux anyway, you're just being honest about it. God, I sound like I'm bullshitting so very hard here... I'm not really a front-end person myself either, but SQL and web dev are two things that are hard to escape entirely in this business.And at least React actually makes it somewhat pleasant, which I thought was impossible.
|
|
#
?
Jan 2, 2019 19:36
|
|
|
redux is an effective blunt instrument, but it's really just a whole lot of machinery around a simple queue. one problem is it conflates the concept of 'single source of truth' with having literally a single object that contains the entire state of your application. the whole reducer thing is basically built around turning what would otherwise be one giant race condition into a workable data store. in fact, having a single root object does not preclude you (or even discourage you, by design) from storing the same data at multiple points in your store, which is what 'single source of truth' is supposed to prevent. you can do something similar with rxjs: define your controller classes to expose rxjs observables for all UI properties and a 'createView' method that creates a "dumb" view component with its props wired to those observables. the root controller creates the rootView, and if the root controller has any nested controllers, then it is responsible for creating them and passing their views (via props) to the parent view component. for a particular observable, if you want the controller to be the single source of truth, you can use a BehaviorSubject and store it directly, otherwise pipe in (via constructor injection) another observable to derive it from. if you use a top-level scan over a stream of actions with the accumulator representing your data store, then you've just re-invented redux.
|
|
#
?
Jan 2, 2019 19:46
|
|
|
Mahatma Goonsay posted:render props are now lame and hooks are the new flavor of the month (even though they are like at an alpha state right now) I've only spent about five minutes looking at hooks but they seem godfuckingawful. IIUC they're a magic shorthand for writing instance variables inside function components, except that none of this has language support so the magic breaks unless you obey a bunch of rules (like always calling the magic "declare a state variable" pragma-esque function unconditionally) that no tools are going to check for you. All for the sake of saving three lines of code. It's the sort of crap I'd expect out of Boost and C++. Just use a class component and declare a state, gdi. Maybe I'm just misunderstanding, I don't know.
|
|
#
?
Jan 2, 2019 19:49
|
|
|
I haven’t really touched react in like a year, so this is interesting
|
|
#
?
Jan 2, 2019 20:53
|
|
|
My teams code-base:quote:git branch -a |wc -l Not bad, we will be down to around 5 tonight. India's code-base: quote:git branch -a |wc -l 
|
|
#
?
Jan 2, 2019 22:12
|
|
|
i'll take "devs who never clean up after themselves" for $400, alex # oneiros at MBP.local in ~/Workspace/primary_service on git:master ● [13:23:57] → git branch -a | wc -l 2278 Oneiros fucked around with this message at 22:35 on Jan 2, 2019 |
|
#
?
Jan 2, 2019 22:31
|
|
|
Oneiros posted:i'll take "devs who never clean up after themselves" for $400, alex Jesus. It's worse than that. They are using the branches as tags. But also also, there is no develop or staging branch.  Edit* I wrote a script that I periodically run when I think we have to many branches. It merges with the develop branch, and then diffs the branch with develop. If there aren't any differences the branch is marked for deletion in an autogenerated script. Branches with merge conflicts and differences are dumped to a seperate text file for review. It's a pretty handy script! edit edit* The Indian team's project is so convoluted that I had to log into a LIVE PRODUCTION server and dump the SQL database to figure out what version was live because they don't print the version name on the website and there's no information as to what branch is currently live. 
FlapYoJacks fucked around with this message at 22:41 on Jan 2, 2019 |
|
#
?
Jan 2, 2019 22:37
|
|
|
ratbert90 posted:Jesus. uh, what's your deployment pipeline look like? i'd hope it'd record some information on what the hell gets shipped to prod. that seems more problematic than devs dirtying up the git repo with feature branches.
|
|
#
?
Jan 2, 2019 22:45
|
|
|
Oneiros posted:uh, what's your deployment pipeline look like? i'd hope it'd record some information on what the hell gets shipped to prod. that seems more problematic than devs dirtying up the git repo with feature branches. Oh believe me, it's BAD and India is on it's way out. Current steps: 1) Send to Jenkins 2) If a magic string is in the commit message, then upload to S3 3) The deployment server checks S3 on a cron job using a bash script 4) If there's a new tarball (no sha sum checking here folks!), then download it, remove the old poo poo, replace it with the new poo poo, and restart Tomcat. Also, don't check to see if any of this passes or even works. Also to pass Jenkins it has to: 1) Build There are no unit tests. 611K lines of Code, 15 unit tests, 0.0% coverage, 30.6% code Duplications, 36K Warnings.
|
|
#
?
Jan 2, 2019 22:49
|
|
|
pedal to the metal performance, no bells or whistles to slow you down! i like it also lol at the 15 unit tests, i bet at some point someone or someones got in that mood where from now on we're testing everything and then a week later 
|
|
#
?
Jan 2, 2019 23:11
|
|
|
|
| # ? Apr 25, 2024 12:33 |
|
|
Deep Dish Fuckfest posted:pedal to the metal performance, no bells or whistles to slow you down! 0.0% coverage, those are some good tests
|
|
#
?
Jan 2, 2019 23:13
|
|
