|
Thermopyle posted:You do have to be careful that you're not just moving complexity from a thunk to a middleware. No gain in doing that. Those are both benefits in my mind. Isolating complexity in middleware vs a thunk that pops up every so often in your action creators leads to easier unit tests and less risk of bugs in your action creators. Your business logic doesn't care about the details of how asynchonicity is handled in JS. Those actions are fired at a distance from your business logic, but that's because the middleware is for non-business logic magic. A positive side affect of that last sentence is that you tend to share these types of actions across multiple reducers more, which is a good thing. I agree with the last few posters that writing your own middleware is harder than using a thunk. I've found that eventually in some apps, there's a point where even worse ceremony is happening inside of your action creators, and trying to add new action creators or action in the middle of a thunk is horrible. I wouldn't recommend my approach until you're feeling pain. luchadornado fucked around with this message at 19:21 on Mar 12, 2017 |
#
?
Mar 12, 2017 19:16
|
|
|
|
| # ? Jun 8, 2024 05:39 |
|
|
Helicity posted:Those are both benefits in my mind. Isolating complexity in middleware vs a thunk that pops up every so often in your action creators leads to easier unit tests and less risk of bugs in your action creators. Your business logic doesn't care about the details of how asynchonicity is handled in JS. Those actions are fired at a distance from your business logic, but that's because the middleware is for non-business logic magic. A positive side affect of that last sentence is that you tend to share these types of actions across multiple reducers more, which is a good thing. I think they can be benefits.
|
|
#
?
Mar 12, 2017 19:42
|
|
|
Anybody here using immutable.js with redux? Not sure if I should try using it for state representation, or go with plain javascript objects/arrays.
|
|
#
?
Mar 12, 2017 20:17
|
|
|
Forgall posted:Anybody here using immutable.js with redux? Not sure if I should try using it for state representation, or go with plain javascript objects/arrays. My company does, though I'm still pretty junior so I don't touch it as much as I'd like to. It seems to work well for us (in the sense that I haven't heard anyone bitching about it, at least).
|
|
#
?
Mar 12, 2017 20:41
|
|
|
Helicity posted:Those are both benefits in my mind. Isolating complexity in middleware vs a thunk that pops up every so often in your action creators leads to easier unit tests and less risk of bugs in your action creators. Your business logic doesn't care about the details of how asynchonicity is handled in JS. Those actions are fired at a distance from your business logic, but that's because the middleware is for non-business logic magic. A positive side affect of that last sentence is that you tend to share these types of actions across multiple reducers more, which is a good thing. If I ever get power back (day five and counting!) I'm going to effortpost how I use thunk to do what your custom middleware does. Basically I have "services" that abstract out all the stuff you do in your middleware so my thunks are basically: code:
|
|
#
?
Mar 12, 2017 21:11
|
|
|
Lumpy posted:If I ever get power back (day five and counting!) I'm going to effortpost how I use thunk to do what your custom middleware does. Basically I have "services" that abstract out all the stuff you do in your middleware so my thunks are basically: Your action creators shouldn't have synchronization logic in them because it makes them brittle. As simple as that example is, there isn't an argument that it's as bulletproof as just returning an action object. My action creators used to look like that, and then you need to add something, and then it needs to work on an interval, and then you have a bug somewhere in there, etc.. Unit tests for that will be a PITA as well. You don't need to do an effort post on it, because I understand exactly what you're doing and have done it a lot. I'm not trying to convince anyone that Thunks are wrong and they're bad developers for using them. I'm just saying I was using Thunks and Sagas, I hated dealing with them at a certain point as apps scale, I tried a new way, and it feels really, really good. Like light-bulb going off in my head kind of way. Forgall posted:Anybody here using immutable.js with redux? Not sure if I should try using it for state representation, or go with plain javascript objects/arrays. I am, and I like it, but there are two caveats: you have to be careful with your fromJS/toJS use or you can affect performance, and it doesn't play well with Typescript. You pretty much need to carry your Immutable objects all the way down into your components and then do a get() with a magic string. I still haven't solved the latter issue to my liking.
|
|
#
?
Mar 13, 2017 01:00
|
|
|
Helicity posted:It's a lot of churn that is even more apparent when you have experience in a more stable ecosystem like Java, Python, or C# (even including Core CLR). One problem is the tendency towards modular architectures that make documenting the interaction between modules critical, but most authors consider that outside the scope of their concerns. The other problem is that documentation in general is poor for many of these projects, so blog posts and tweets are useful sources of information but become outdated very quickly. A React boilerplate from 2015 can be unusable in 2017, for example. Steps are being made, so there's hope - Redux and Webpack both got healthy updates to their documentation. That's fair, and definitely an angle I hadn't considered. Most of the griping I've seen comes from a place of "I can just make that todo list example app with jQuery." quote:...Middleware code This is really cool. My thunks are definitely looking like your first example there. I've been thinking about making the move to Sagas for my next project but maybe I'll try this middleware approach instead. I think something about middleware has made me just ignore it after I get my initial app set up, like it's a place for general plugins and extensions and not application code. Thanks for sharing!
|
|
#
?
Mar 13, 2017 05:01
|
|
|
Helicity posted:I am, and I like it, but there are two caveats: you have to be careful with your fromJS/toJS use or you can affect performance, and it doesn't play well with Typescript. You pretty much need to carry your Immutable objects all the way down into your components and then do a get() with a magic string. I still haven't solved the latter issue to my liking.
|
|
#
?
Mar 13, 2017 08:28
|
|
|
Forgall posted:I'm also trying to use it with typescript, and I found this which seems to work pretty nice. That's cool, Immutable Records were a pain in the rear end to use directly with Typescript, which is unfortunate given how powerful the two go together. I said in another thread that if I had to choose between static typing and immutability, immutability would probably win. It's so very useful to know that your values are exactly what they're supposed to be, with no questions of whether particularly methods mutated them or whatever. But either way, it's very nice to have both.
|
|
#
?
Mar 13, 2017 09:39
|
|
|
In a SaaS environment, what's your preference: pushing with websockets, or RESTful pulling? I can see benefits of both and we're currently architecting into a RESTful consumption model for simplicities sake, but I can't help feeling that early designing of a websockets push environment will be stronger in the long run. Anyone got any preferences, or experience going from one architecture to the other? Have you run both at once?
|
|
#
?
Mar 13, 2017 10:41
|
|
|
Plavski posted:In a SaaS environment, what's your preference: pushing with websockets, or RESTful pulling? I can see benefits of both and we're currently architecting into a RESTful consumption model for simplicities sake, but I can't help feeling that early designing of a websockets push environment will be stronger in the long run. Anyone got any preferences, or experience going from one architecture to the other? Have you run both at once? I've found this to be good guideline: https://blogs.windows.com/buildingapps/2016/03/14/when-to-use-a-http-call-instead-of-a-websocket-or-http-2-0/ I've done a mix of REST and ws at my last 2 companies. ws was primarily for for pushing high volumes of uncacheable messages in a half-duplex fashion both times. The link above brings up a good point that you might have to spend more time defining your message layer if you're handling full duplex communications. Forgall posted:I'm also trying to use it with typescript, and I found this which seems to work pretty nice. Thanks! I'll have to try that.
|
|
#
?
Mar 13, 2017 14:06
|
|
|
Helicity posted:I've found this to be good guideline: https://blogs.windows.com/buildingapps/2016/03/14/when-to-use-a-http-call-instead-of-a-websocket-or-http-2-0/ That was really helpful thanks.
|
|
#
?
Mar 13, 2017 15:37
|
|
|
I thought that since typescript added async/await for es5 target in 2.1 generators were also in, but turns out not 
|
|
#
?
Mar 13, 2017 22:21
|
|
|
Forgall posted:I thought that since typescript added async/await for es5 target in 2.1 generators were also in, but turns out not Yeah, if you look at the code await/async transpile down to in ES5 they have to fake their own generators. It's on the milestone list for 2.3 though: https://github.com/Microsoft/TypeScript/issues/1564
|
|
#
?
Mar 13, 2017 22:42
|
|
|
So I'm slowly, slowly learning Angular (2.X). I'm iterating over some objects: <div *ngFor="let basketitem of basketitems" class="row itemInfo"> but I'd like to sort, and group, by a property. I know sortBy and groupBy were removed from AngularJS because reasons. I wouldn't know where to start to write my own, but I found angular2-pipes. Trouble is, I don't think I installed it properly. I went to the folder that contains /app and /node_modules and did npm install ngx-pipes --save, I see it in package.json. Then in app.module.ts I put import {NgPipesModule} from 'ngx-pipes'; and NgPipesModule in the imports array in @NgModule, but when I try to use it, even by copy/pasting the first example in the docs, it gives an error saying it can't find the pipe. Since I just started learning Angular this is the first plugin I've tried and I know with previous issues I've had with Angular it was just from not importing dependencies properly.
|
|
#
?
Mar 14, 2017 15:34
|
|
|
Is your version of TypeScript up to date? Do you have definition files for that module?
|
|
#
?
Mar 14, 2017 15:41
|
|
|
Plavski posted:Is your version of TypeScript up to date? Do you have definition files for that module? I'm not quite sure how to answer those questions My package.json says "dependencies": { "ngx-pipes": "^1.4.6", } and "devDependencies": { "typescript": "~2.0.10",}. I see an /ngx-pipes folder in node_modules and I started this project using Angular Quickstart
|
|
#
?
Mar 14, 2017 15:53
|
|
|
The Merkinman posted:I'm not quite sure how to answer those questions Angular Quickstart seemed a bit outdated, since you just started you can probably re-init the project with @angular/cli and I'm sure it'll work https://cli.angular.io/
|
|
#
?
Mar 14, 2017 15:57
|
|
|
The Merkinman posted:So I'm slowly, slowly learning Angular (2.X). I'd say they were removed for a good reason... Specifically in Angular 1.x, filtering in the template was 2x as expensive, as it happened during digests and thus, happened at least twice. But from a code maintenance perspective, Angular 1.x tried putting too much logic in the HTML. I'd put your sorting and grouping logic in the controller, and have your template iterate over that, it'll make it a lot easier to tweak later on.
|
|
#
?
Mar 14, 2017 16:58
|
|
|
Skandranon posted:I'd say they were removed for a good reason... Specifically in Angular 1.x, filtering in the template was 2x as expensive, as it happened during digests and thus, happened at least twice. But from a code maintenance perspective, Angular 1.x tried putting too much logic in the HTML. I'd put your sorting and grouping logic in the controller, and have your template iterate over that, it'll make it a lot easier to tweak later on. I understand the reasoning, but given how new I am to Angular I'm having trouble actually doing it
|
|
#
?
Mar 14, 2017 17:13
|
|
|
The Merkinman posted:I understand the reasoning, but given how new I am to Angular I'm having trouble actually doing it Put a get property on your controller like so code:This will then request your new filtered collection upon every digest, but at least your code is in plain JS. To be even more picky about performance, you can have a collection on the controller as you do now, but specific functions that alter it, so you only perform filtering/sorting/grouping when someone clicks a button or changes something. This is much more efficient, but requires diligence.
|
|
#
?
Mar 14, 2017 17:22
|
|
|
Skandranon posted:Put a get property on your controller like so When I try what you suggest: code:
|
|
#
?
Mar 14, 2017 18:09
|
|
|
The Merkinman posted:OK so I should roll my own rather than using a plugin? (which incidentally did seem to work with angular-cli but only as far as importing, still errors, yay) Sorry... I was being a bit brief, filter().sort().group() aren't real functions... I guess it would look more like this.basketitems.filter(b => b.thingIWant).sort((a,b) => a.sortField > b.sortField). Probably some good grouping methods in lodash.
|
|
#
?
Mar 14, 2017 18:19
|
|
|
Skandranon posted:Sorry... I was being a bit brief, filter().sort().group() aren't real functions... I guess it would look more like this.basketitems.filter(b => b.thingIWant).sort((a,b) => a.sortField > b.sortField). Probably some good grouping methods in lodash. Oh I see, just pass the original array and output another? Well I got sorting working, but that grouping. I can't wait until I'm done to share my findings because it seems I'm the first person in the world to want to do something in Angular that was built-in to AngularJS. EDIT: Looks like I can pause this anyway since upon doing so, I realized a bunch of possibilities that we don't have requirements for. The Merkinman fucked around with this message at 21:17 on Mar 14, 2017 |
|
#
?
Mar 14, 2017 20:09
|
|
|
So, I'm working on this huge react app right now, very big, hundreds of components. I'm a junior with .js, but I'm also 100% in charge of the css styles because I'm a whiz (and not junior at all) at that. Anyway, today I had this argument with one of our consultants about component-driven design and how to organize your files. The consultants want all the scss mixed in with the js components, and myself and some of the internal people want it to be in a stylesheet folder so it acts more as a style guide. The business people want to be able to theme this app someday, which isn't necessarily related but it might be. I realize that directory structure is something fairly mundane that people argue PASSIONATELY about, but how valid are his arguments about scalability and confusion, when I'm the one who actually has to refactor this stuff (I came on 75% into the project launching and nobody before me really, truly knew css) and I'm far more comfortable dealing with hundreds of sass files that aren't mixed in with hundreds of .js files when it comes down to actually cleaning it up, removing redundancy, and somehow, some way getting this thing to work on mobile. I've seen arguments for both sides, but nothing that actually addresses an app as huge as this. Usually the 'ideal structure' articles show apps that are 1/10th the size of this thing. Another large thing I've worked on is this game in Unity that is massive, I would never dream of mixing my art assets in with my C# code in that, so it seems sort of odd to do it here. I DO understand that the philosophy is supposed to be 1:1 component/style association, and I'm not actually changing the component-based nature of the build (which is...piecemeal at best, that needs to be worked on, too). And I can see some value of having them together, but as it stands my task to actually improve the overall styles seemed impossible when it was. Anyway, convince me to put them all back or keep them apart I guess. My manager doesn't have strong feelings either way and doesn't actually know what's best. Everyone has an opinion but my only experience with a codebase this big is a massive game project, which is C# rather than React.
|
|
#
?
Mar 15, 2017 00:16
|
|
|
Shayl posted:I would never dream of mixing my art assets in with my C# code in that, so it seems sort of odd to do it here. You're conflating separation of filetypes with separation of concerns. That's probably besides the point though. You want to theme one day. You're also the person that is stuck with this code. Do whatever is more maintainable and allows you to pivot quickly. Write your apps so they're easy to be strangled: https://www.martinfowler.com/bliki/StranglerApplication.html Some consultants love to get on a high horse and pitch "best practices", and you need to be careful around them. Come up with some scenarios: adding theming, extracting large sections of the codebase out into standalone modules, switching from SASS to LESS, etc. Ask your co-workers how separate CSS would help/hinder. Ask the consultants how it would help/hinder in each of those. Make people think about it, and give valid reasons. My gut is that it doesn't really matter, but it would probably be easier to keep them separate from the CSS. I've seen several projects with hundreds of components and the CSS layout has never been the pain point with any of them.
|
|
#
?
Mar 15, 2017 00:53
|
|
|
If someone was gonna say to me, make this themeable, the file locations would be the least of my concerns. Good variables for single points of control and controlling specificity effectively (using BEM or something like that), is far more important for that kind of thing in my mind. That said though, our projects err towards keeping css per component in with the Javascript that renders it, because we believe the separation doesn't exist, given the CSS depends on either the HTML structure (if it's bad CSS), or the HTML classes in order to bind to the component. Separating the files doesn't separate their relationship. If their sass files are actually binding to the component with very specific classes then there really should be no problem, but if the issue is they took a dump over specificity, well, you've got a lot of work ahead of you no matter where you put the sass.
|
|
#
?
Mar 15, 2017 01:01
|
|
|
Helicity posted:
I think this is why my manager doesn't have a strong opinion, where it goes doesn't matter that much to him, and I did this to make it easier for me, the person almost 100% responsible for it, to maintain and improve. I'm the only person with design background in the group and probably the only one who actually tries to maintain the visual style guide given to us. Maluco Marinero posted:If someone was gonna say to me, make this themeable, the file locations would be the least of my concerns. Good variables for single points of control and controlling specificity effectively (using BEM or something like that), is far more important for that kind of thing in my mind. That said though, our projects err towards keeping css per component in with the Javascript that renders it, because we believe the separation doesn't exist, given the CSS depends on either the HTML structure (if it's bad CSS), or the HTML classes in order to bind to the component. Separating the files doesn't separate their relationship. Some bind to the component, some don't, its a bit all over the place (the way components were used wrong in the early part of the project is part of our technical debt). Heck, the reason I decided to get the files all in one place was so I could actually look at them from a high level and start to plan out what to do to make things more consistent with good variables and other things. (We're like, half BEM namespace and half bullshit td > td > td bla bla garbage)
|
|
#
?
Mar 15, 2017 01:52
|
|
|
Shayl posted:I think this is why my manager doesn't have a strong opinion, where it goes doesn't matter that much to him, and I did this to make it easier for me, the person almost 100% responsible for it, to maintain and improve. I'm the only person with design background in the group and probably the only one who actually tries to maintain the visual style guide given to us. The modular approach is nice if multiple developers are contributing to the styles. But if there is a more clear separation of developer vs designer, then I think it makes perfect sense to have a set styles folder with your own layout. And as Helicity said, if you are the main contributor, then do what you think it in your bests interests. Even if their way IS objectively 'better', there is value in YOU being able to work effectively, and this has to be taken into consideration and balanced. If they aren't actually going to be doing much style work, they have little leg to stand on in saying how it should be laid out. I personally hate doing CSS work, so I go out of my way (within reason) to make the designers happy in how they want to structure things so I don't have to touch it.
|
|
#
?
Mar 15, 2017 01:58
|
|
|
Skandranon posted:The modular approach is nice if multiple developers are contributing to the styles. But if there is a more clear separation of developer vs designer, then I think it makes perfect sense to have a set styles folder with your own layout. And as Helicity said, if you are the main contributor, then do what you think it in your bests interests. Even if their way IS objectively 'better', there is value in YOU being able to work effectively, and this has to be taken into consideration and balanced. If they aren't actually going to be doing much style work, they have little leg to stand on in saying how it should be laid out. Yep, I was literally hired because all the devs hate CSS and I like it and have a lot of experience with it. None of them have written any CSS for months.
|
|
#
?
Mar 15, 2017 02:12
|
|
|
Shayl posted:Yep, I was literally hired because all the devs hate CSS and I like it and have a lot of experience with it. None of them have written any CSS for months. Yep, do what's best for you in that environment. Honestly I feel like with CSS, otherwise good programmers seem to make absolutely brain-dead lower tier mistakes. Like, the specificity is a CSS thing, but then stuff like good mixins to reduce repetition and variables to reduce magic numbers to single points of control never seems to occur to people properly when working a design system. It feels like you've got the right approach though, you need to audit before you figure out what to put in it's place. Honestly CSS doesn't take that long to write, sometimes even a rewrite is the best way to unfuck a CSS system.
|
|
#
?
Mar 15, 2017 02:25
|
|
|
You're the one who's going to deal with them, so you make the call. You're the professional CSS guy, you get your respect! Personally, I wrap my scss up next to my ts for compartmentalised goodness. I then uss SASS's programmatic loveliness to keep a central theme in one place and distribute the values out. I modelled it on Semantic-UI's theming structure: https://semantic-ui.com/usage/theming.html
|
|
#
?
Mar 15, 2017 10:58
|
|
|
Plavski posted:You're the one who's going to deal with them, so you make the call. You're the professional CSS guy, you get your respect! Thanks for this, I was looking for a good example of how I wanted to do theming for this project, and someone else here also mentioned Semantic UI.
|
|
#
?
Mar 15, 2017 14:05
|
|
|
Shayl posted:Thanks for this, I was looking for a good example of how I wanted to do theming for this project, and someone else here also mentioned Semantic UI. Note that if you're going the SASS route, you should probably read up on the issues Semantic has with SASS: https://github.com/Semantic-Org/Semantic-UI/issues/1147 The issue is that SASS doesn't support dynamic compilation based on variables in import strings, so theming by URL is out. It's why they use LESS. Not really an issue for us as themes aren't on our roadmap for a couple of years, and hopefully by that time SASS will have unfucked itself. Important to know tho, and I'd recommend checking out Bootstrap and Foundation for the way they use SASS and handle themes too.
|
|
#
?
Mar 15, 2017 15:15
|
|
|
Plavski posted:Note that if you're going the SASS route, you should probably read up on the issues Semantic has with SASS: https://github.com/Semantic-Org/Semantic-UI/issues/1147 Why not generate all of them up-front as part of your build/deploy step by pointing SASS at a file that sets colors+measurements and includes the generic SASS files?
|
|
#
?
Mar 15, 2017 18:58
|
|
|
I'm running a Flask website that has a form that queries all images in a folder, and the corresponding thumbnails folder, on the server given a specific date range. I was originally planning to just put this into the front end with a JS LazyLoading script. However, there could be a thousand images to display and all the HTML that surrounds the image is making the page really long. I feel like I'm almost there with LazyLoading. Any thoughts?
|
|
#
?
Mar 15, 2017 19:21
|
|
|
Munkeymon posted:Why not generate all of them up-front as part of your build/deploy step by pointing SASS at a file that sets colors+measurements and includes the generic SASS files? That's what we do. Our component scss is inline with our ts so developers working on them can just use their own little bit of scoped css without worrying about affecting anything else. Our gulp scripts scoop it all up and compile it all with the top level variables and dump out the css that webpack lumps together alongside Aurelia. I quite like that pattern and picked it up playing around with Semantic. Their LESS situation allows them to do dynamic compilation with themenames in the *.less files. SASS won't let you do that easily, so that's why we're hardcoding everything to a default theme for the time being. I imagine when expansive theming bubbles up off the backlog, we'll either do it in SASS's (hopefully new) native import shenanigans, or just use mixins. Our graphic designer is often too busy loving around with Framer and Sketch to get down to the nitty gritty of CSS, so it's left to the devs instead. Not having a top-level one-stop-shop for everything makes it easier for us to parcel out work and not tread on each others toes, but I can't help feeling that one day our art guy is gonna get really annoyed that he has to think to find out where something is styled.
|
|
#
?
Mar 15, 2017 19:31
|
|
|
I'm having a problem with how determining what could be a component in a Rails + Vue app. The app has two dynamic sidebars, a couple of info bars, etc, and it all comes from a server-rendered html.erb. A lot of components have "inline-template" so it looks like a mess but I'm not sure moving a form outside the template where it's used makes sense. Anyone else doing this kind of mix?
|
|
#
?
Mar 16, 2017 19:26
|
|
|
Is there a starting point that people use for React projects? Or do you tend to roll your own backend + webpack + Babel + whatever? Just getting to Hello World in React is such a pain in the rear end to get working. I should save a template some day as a starting point.
|
|
#
?
Mar 16, 2017 19:48
|
|
|
|
| # ? Jun 8, 2024 05:39 |
|
|
K so here's a general discussion topic, as I am looking for opinions on how to accomplish something like this. So last place I worked had a configuration service which was call whenever the web app was bootstrapping, and it would return a list of feature flags for whatever environment you were running on. So dev.config.json for dev, qa.config.json for QA, etc. The Pros were: - code, assuming it's working is merged into all branches: dev, qa, staging, prod, etc. - if a feature flag is turned off - that code isn't available. (can be done via routing, or even just checking the flags directly in code.) - when a feature is finally complete a "release" is merely turning on the feature flag - regression testing becomes a lot simpler, because the code in pre-prod say - isn't any different from code in qa. You can turn flags on and off for each environment. - you stop thinking as a "release" as an "arbitrary group of features released on an equally arbitrary date" and more of as "feature releases" - a rollback (if needed) simply consists of turning the flag back off until the issue can be addressed at a lower environment. - no need to maintain something like a production branch vs a dev branch. Everything is merged - just gated off behind flags. Dev would probably have all flags enabled. Prod would have a subset.] - forces you to think of your features in very modular terms - since you have to encapsulate well to gate off something behind a feature flag - can "release" often since they are WAY smaller and relatively painless. Cons: - this did take a LOT of effort to get setup and working, and most of that was done before I got there. This means I am likely even now WAY underestimating the LOE required. - requires a pretty solid bootstrapping process, and appropriate failover paths in case for some reason the app can't hit the config server (default config? Just an error message saying the app is unavailable?) - murky waters when it comes to something like: edge case code that might only be used in one place which were hung off of some common object somewhere because there wasn't a better place - or someone was too lazy to make it its own module like they should have, and now the module it's hanging off of needs to be gated off but you can't because of this one corner case, etc. So....has anyone here implemented anything similar to this? I suppose our eventual goal is something approaching continuous integration and this seemed like a decent interim solution. I have worked ONE place that did CI - releases every day at 10am and 3pm. If you missed one train you just got on the next - and it was SO low-pressure it was amazing. But the way that app was designed was pretty much tailor made for that scenario, so that seems a bit pie-in-the-sky for this project. But I'd like to get to somewhere better than "pick a date X amount of time in the future - see how many things we can reasonably (and sometimes not so reasonably) stuff into the codebase before then - call it a release"
|
|
#
?
Mar 16, 2017 19:48
|
|
