Could use some quick feedback on whether this build is overpriced
-
@Dashrender said:
@creayt said:
@Dashrender said:
Why are you doing this dev locally? Why not get a server? or get some compute power from a provider?
I actually have a handful of servers. Developing locally, at least w/ my workload, ends up being much, much faster because you don't have to wait for what can end up being hundreds of http requests per second.
At this point me saying anything feels more like I'm being an ass - but I'll one thing before leaving it alone.
If you're entire loadup/install/whatever you wanna call it, is on the cloud/hosted/etc remote solution, why would those http requests be any slower to that box itself, than it would be on your local machine? of course, the purchased resources might be more expensive in the cloud - and that could be a reason for your request.
This reminds me of the doctor who was demanding sub-second response to every click in his remotely hosted/cloud based EHR, something that just seems unrealistic (unrealistic for his demand - in your single dev setup, with a local install, and huge amounts of cash - totally doable).
Because when you develop locally they don't even exist, your box feeds your box and doesn't even go out to the web, and the latency is ~0 ms.
-
@Dashrender said:
@creayt said:
@Dashrender said:
Why are you doing this dev locally? Why not get a server? or get some compute power from a provider?
I actually have a handful of servers. Developing locally, at least w/ my workload, ends up being much, much faster because you don't have to wait for what can end up being hundreds of http requests per second.
At this point me saying anything feels more like I'm being an ass - but I'll one thing before leaving it alone.
If you're entire loadup/install/whatever you wanna call it, is on the cloud/hosted/etc remote solution, why would those http requests be any slower to that box itself, than it would be on your local machine? of course, the purchased resources might be more expensive in the cloud - and that could be a reason for your request.
This reminds me of the doctor who was demanding sub-second response to every click in his remotely hosted/cloud based EHR, something that just seems unrealistic (unrealistic for his demand - in your single dev setup, with a local install, and huge amounts of cash - totally doable).
If you're suggesting working directly on the server as a remote workstation w/ remote desktop, when you write and test code and overall navigate an OS very, very fast, the latency of remote desktop is unacceptable. I've tried to work like that at various points, it slows me down. I prototype and test extremely quickly and basically any, even momentary, lag or twitch in my workflow slows me down and makes it feel like working on a mac, which gets my blood pressure up.
-
You lost me? What doesn't exist?
-
@creayt said:
If you're suggesting working directly on the server as a remote workstation w/ remote desktop, when you write and test code and overall navigate an OS very, very fast, the latency of remote desktop is unacceptable. I've tried to work like that at various points, it slows me down. I prototype and test extremely quickly and basically any, even momentary, lag or twitch in my workflow slows me down and makes it feel like working on a mac, which gets my blood pressure up.
yep, that's what the doctor said - he wanted paper charts back because he could flip as fast as his fingers could get him to a page - nevermind the fact that he couldn't get any data at all when he was a home or in the OR across town.
-
@Dashrender said:
why would those http requests be any slower to that box itself, than it would be on your local machine?
My box doesn't have to execute the http requests to a remote box at all, it just gets the queries and media and assets from itself, so there's 0ms lag instead of X requests * randomLag( ).
-
@creayt said:
@Dashrender said:
why would those http requests be any slower to that box itself, than it would be on your local machine?
My box doesn't have to execute the http requests to a remote box at all, it just gets the queries and media and assets from itself, so there's 0ms lag instead of X requests * randomLag( ).
yes my thinking was for you to work remotely from the server where ever it was hosted (vm or physical) - but you've shot that down with the latency issue. Which I suppose I can understand.
-
@Dashrender said:
yep, that's what the doctor said - he wanted paper charts back because he could flip as fast as his fingers could get him to a page - nevermind the fact that he couldn't get any data at all when he was a home or in the OR across town.
Hahahah. No, I think you're misunderstanding something in the chain. When you develop locally you still have a full, up to the moment copy of the data. It's called replication.
-
@creayt said:
@Dashrender said:
yep, that's what the doctor said - he wanted paper charts back because he could flip as fast as his fingers could get him to a page - nevermind the fact that he couldn't get any data at all when he was a home or in the OR across town.
Hahahah. No, I think you're misunderstanding something in the chain. When you develop locally you still have a full, up to the moment copy of the data. It's called replication.
That's not possible, otherwise your latency would be killing you just the same.
-
A quick ballpark of the price for parts alone, before a case and Windows is just over 1500 so it seems reasonable.
-
@Dashrender said:
That's not possible, otherwise your latency would be killing you just the same.
Hahhahaahha. Oh oops, guess even though I do it I just have no idea what I'm talking about and am making stuff up.
It's not only very possible, but very simple. The replication pushes each data delta to my local database install in the background, and I have a separate copy of it that I'm developing against, and whenever I want to refresh the dev copy ( which isn't something you do very often at all during development ), I click another button and voila. So I have a live, up to the moment copy of the data at all times available locally w/ no wait, and then I work off of a moment-in-time copy of that. I hope that all makes sense.
-
@DustinB3403 said:
A quick ballpark of the price for parts alone, before a case and Windows is just over 1500 so it seems reasonable.
Thank you very much, exactly what I was looking for.
-
@creayt said:
@Dashrender said:
That's not possible, otherwise your latency would be killing you just the same.
Hahhahaahha. Oh oops, guess even though I do it I just have no idea what I'm talking about and am making stuff up.
It's not only very possible, but very simple. The replication pushes each data delta to my local database install in the background, and I have a separate copy of it that I'm developing against, and whenever I want to refresh the dev copy ( which isn't something you do very often at all during development ), I click another button and voila. So I have a live, up to the moment copy of the data at all times available locally w/ no wait, and then I work off of a moment-in-time copy of that. I hope that all makes sense.
Yes you're working off a moment in time copy - of that I agree with, but you can't be working with the live data continuously assuming the live data is on another server somewhere else because that would require a continuous live stream of replication and the aforementioned latency.
-
@Dashrender said:
Yes you're working off a moment in time copy - of that I agree with, but you can't be working with the live data continuously assuming the live data is on another server somewhere else because that would require a continuous live stream of replication and the aforementioned latency.
I didn't say working w/ ( [on] ) the live data. You wouldn't want to do that in development, that'd get you fired after a while.
What I said: "When you develop locally you still have a full, up to the moment copy of the data. It's called replication."
What that means is that any time anyone ( or any event ) saves a change ( on a remote CMS for example ), that copy of the database sends just the data change down to your local database install and updates the replicated copy. There's a small latency ( one request's worth typically ), but it's happening asynchronously in the background and isn't perceptible.
This may help if you're interested in learning more: http://dev.mysql.com/doc/refman/5.7/en/replication.html
-
@creayt said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Why are you doing this dev locally? Why not get a server? or get some compute power from a provider?
THis is like the tenth thread of people asking him that
Does this imply that this is also the 10th thread without an answer?
If it's any consolation, I think most developers develop locally in 2015.
All that I am aware of. I know that some don't, but I've not run into them yet.
-
@Dashrender said:
This reminds me of the doctor who was demanding sub-second response to every click in his remotely hosted/cloud based EHR, something that just seems unrealistic (unrealistic for his demand - in your single dev setup, with a local install, and huge amounts of cash - totally doable).
No reason a remotely hosted app can't return a sub second response time, that's actually completely standard. ML does that even when accessing huge amounts of data from a really busy database with thousands of users on the site at the same time. Guaranteeing that every click, always does that would be a little much. But having 90% of clicks respond in way under a second would be just normal, good app design. If he even needs to ask for that there is something wrong with the product offerings out there.
-
@Dashrender said:
@creayt said:
If you're suggesting working directly on the server as a remote workstation w/ remote desktop, when you write and test code and overall navigate an OS very, very fast, the latency of remote desktop is unacceptable. I've tried to work like that at various points, it slows me down. I prototype and test extremely quickly and basically any, even momentary, lag or twitch in my workflow slows me down and makes it feel like working on a mac, which gets my blood pressure up.
yep, that's what the doctor said - he wanted paper charts back because he could flip as fast as his fingers could get him to a page - nevermind the fact that he couldn't get any data at all when he was a home or in the OR across town.
Why was the app unable to keep up with paper flipping? That shouldn't be a problem from a technical level.
-
@Dashrender said:
@creayt said:
@Dashrender said:
yep, that's what the doctor said - he wanted paper charts back because he could flip as fast as his fingers could get him to a page - nevermind the fact that he couldn't get any data at all when he was a home or in the OR across town.
Hahahah. No, I think you're misunderstanding something in the chain. When you develop locally you still have a full, up to the moment copy of the data. It's called replication.
That's not possible, otherwise your latency would be killing you just the same.
Why? Where does the latency come from?
-
@Dashrender said:
@creayt said:
@Dashrender said:
That's not possible, otherwise your latency would be killing you just the same.
Hahhahaahha. Oh oops, guess even though I do it I just have no idea what I'm talking about and am making stuff up.
It's not only very possible, but very simple. The replication pushes each data delta to my local database install in the background, and I have a separate copy of it that I'm developing against, and whenever I want to refresh the dev copy ( which isn't something you do very often at all during development ), I click another button and voila. So I have a live, up to the moment copy of the data at all times available locally w/ no wait, and then I work off of a moment-in-time copy of that. I hope that all makes sense.
Yes you're working off a moment in time copy - of that I agree with, but you can't be working with the live data continuously assuming the live data is on another server somewhere else because that would require a continuous live stream of replication and the aforementioned latency.
You develop with copies of data, not with live data. Can't think of any case where having live data would be beneficial or useful to developers. No reason to have data coming from remote or external at all.
It's absolutely standard for developers to have local databases for development. I've worked in huge shops with hundreds of developers doing this all the time. It's not just possible it's the norm. So much so, it is just expected.
-
@scottalanmiller said:
@Dashrender said:
@creayt said:
@Dashrender said:
That's not possible, otherwise your latency would be killing you just the same.
Hahhahaahha. Oh oops, guess even though I do it I just have no idea what I'm talking about and am making stuff up.
It's not only very possible, but very simple. The replication pushes each data delta to my local database install in the background, and I have a separate copy of it that I'm developing against, and whenever I want to refresh the dev copy ( which isn't something you do very often at all during development ), I click another button and voila. So I have a live, up to the moment copy of the data at all times available locally w/ no wait, and then I work off of a moment-in-time copy of that. I hope that all makes sense.
Yes you're working off a moment in time copy - of that I agree with, but you can't be working with the live data continuously assuming the live data is on another server somewhere else because that would require a continuous live stream of replication and the aforementioned latency.
You develop with copies of data, not with live data. Can't think of any case where having live data would be beneficial or useful to developers. No reason to have data coming from remote or external at all.
It's absolutely standard for developers to have local databases for development. I've worked in huge shops with hundreds of developers doing this all the time. It's not just possible it's the norm. So much so, it is just expected.
I didn't understand his need for the live, or near live data either, but he said he was getting replication of the data. If - IF he was waiting for real time live replication (which is how I took his comment), then he would have the latency of waiting for that remote data to replicate before he ran his queries.
Of course that's not what he's doing. He's running a replication, and then running his query on a point in time (presumably the most recent one available without waiting).
After that we were just playing a word game, so I disengaged.
-
@Dashrender said:
After that we were just playing a word game, so I disengaged.
One of us may have been playing a word game, but if so they were playing it alone.
