Well, I'm building a small web server for small business clients. Multiple sites on one Linode. My main concern is that while most of them will be glorified blogs, one client wants to venture out into the world of e-commerce sometime in the next year, and I want to do what I can to keep downtime minimal (if not 0) for updates if/when that happens.
Basically, just trying to future-proof myself now instead of kludging something together last minute.
The big problem with our deployments is that while we can keep the services up easily with our load-balancing and rolling restarts, we have to have a hard cutoff anyways due to database migration. I can't be still be processing requests, I have to stop and then start the migration script and then start the new applications.
Fortunately the migration doesn't take long so far so it's not a lot of downtime.
Back in my old MySQL days we had that issue where db migrations would lock up large tables and take things down for a few minutes. I believe Postgres, at least more modern incarnations of it, are smarter and I have never run into such an issue.
The db migrations do still get us sometimes, though. We try to do commits and deploys which only have the schema migrations and in a way where the old code works with the new fields, then deploy the code which uses those new fields separately, then backfill data. It doesn't always work out that way, though, and we will sometimes get a hiccup where the migrations and code changes go out at the same time and then some server gets updated and restarted before the migrations have happened.
That could also be resolved by scripting our deploys more rather than just doing an all out opsworks deploy of everything. I've solved it on our amazon ECS based platforms by building a system which runs a task which does the db migrations first, when those complete successfully, then services are updated with the new code/images. I just need to build a similar thing for opsworks... but really I want to stop using opsworks anyway, for the most part.
woohoo, S3 is crashing and burning right now. It's taken out a ton of sites, including crippling ours. Guess we need to look into gracefully handling service degradation a little better.
Anyone have any strong opinions on Xamarin vs React Native for a non-mobile developer? I'm leaning towards Xamarin because I prefer C# to JS (although I don't have heavy experience with either), but I'm willing to listen to anyone with experience either way.
0
Options
SmasherStarting to get dizzyRegistered Userregular
This was after debugging the umpteenth race condition, because multithreaded programming is hard when all you have are event flags and volatile variables that aren't even guaranteed by the standard to be atomic.
Concurrency without immutability makes my eyes bleed.
In embedded systems, you don't get immutability, because it all costs memory. All must bow before the altar of optimizing for size!
It's getting better nowadays, though. A lot more platforms are appearing that run ARMs in the 800MHz-1GHz+ region, with gigs of RAM, thanks to smartphones making this class of processors popular.
I say this, as I prepare to head back to work on an ARM926EJ, with a suspected lack of a branch prediction unit, which means that conditionals in the inner loop have a massive penalty if not taken... At least that's the working theory. The reference manual for the device is no longer available due to the age of the product, haha, so I can't check.
Is this what you mean? I'm not sure if the ARM926EJ-S is a different model than you're using, or if you're looking for something else.
Anyone have any strong opinions on Xamarin vs React Native for a non-mobile developer? I'm leaning towards Xamarin because I prefer C# to JS (although I don't have heavy experience with either), but I'm willing to listen to anyone with experience either way.
You don't need to use JS with React Native. You can use Clojurescript or Typescript. I have never used the JS RN workflow, but the re-natal experience in Cljs is positively great. Unfortunately, I have no experience with Xamarin.
In the end, it's not a huge effort to try and use both and figure out which one you prefer, so you should probably sink the time and do so.
S3 is currently down. Not that you would know from the AWS status page as it is showing everything normal. This is because status information is hosted in S3, which is down.
This was after debugging the umpteenth race condition, because multithreaded programming is hard when all you have are event flags and volatile variables that aren't even guaranteed by the standard to be atomic.
Concurrency without immutability makes my eyes bleed.
In embedded systems, you don't get immutability, because it all costs memory. All must bow before the altar of optimizing for size!
It's getting better nowadays, though. A lot more platforms are appearing that run ARMs in the 800MHz-1GHz+ region, with gigs of RAM, thanks to smartphones making this class of processors popular.
I say this, as I prepare to head back to work on an ARM926EJ, with a suspected lack of a branch prediction unit, which means that conditionals in the inner loop have a massive penalty if not taken... At least that's the working theory. The reference manual for the device is no longer available due to the age of the product, haha, so I can't check.
I'm waiting for the day when I won't get yelled at for using virtual functions and can pass around std::functions.
Anyone have any strong opinions on Xamarin vs React Native for a non-mobile developer? I'm leaning towards Xamarin because I prefer C# to JS (although I don't have heavy experience with either), but I'm willing to listen to anyone with experience either way.
i'm assuming your phrasing implies that you're trying to deploy a multi-platform mobile app?
i disagree with React, but in general you're better off with whatever you end up putting in your web view
This was after debugging the umpteenth race condition, because multithreaded programming is hard when all you have are event flags and volatile variables that aren't even guaranteed by the standard to be atomic.
Concurrency without immutability makes my eyes bleed.
In embedded systems, you don't get immutability, because it all costs memory. All must bow before the altar of optimizing for size!
It's getting better nowadays, though. A lot more platforms are appearing that run ARMs in the 800MHz-1GHz+ region, with gigs of RAM, thanks to smartphones making this class of processors popular.
I say this, as I prepare to head back to work on an ARM926EJ, with a suspected lack of a branch prediction unit, which means that conditionals in the inner loop have a massive penalty if not taken... At least that's the working theory. The reference manual for the device is no longer available due to the age of the product, haha, so I can't check.
Is this what you mean? I'm not sure if the ARM926EJ-S is a different model than you're using, or if you're looking for something else.
Useful! No mention of a branch predictor in there - most research on other processors of that era using the ARM926EJ-S core indicate a lack of branch predictors. Branch prediction actually seems to be a more "recent" addition to the ARM family, to be honest.
Either way, I'm fine with removing the branches. It's an inner loop where I can provide branchless specialisations of the 2 common cases, which cover like 95%+ of all use cases, so I'm not too fussed. Gotta keep those pipelines fed!
Well, I'm building a small web server for small business clients. Multiple sites on one Linode. My main concern is that while most of them will be glorified blogs, one client wants to venture out into the world of e-commerce sometime in the next year, and I want to do what I can to keep downtime minimal (if not 0) for updates if/when that happens.
Basically, just trying to future-proof myself now instead of kludging something together last minute.
Set the server up either with rocketeer or Capistrano and you'll be good to go. They both work on the premise that code is copied to a versioned folder on the server, composer, etc is run and then when everything is ready it'll switch a symlink from the last version to your current version and you'll be running live code. Followed by a graceful Apache restart which will restart the server so it picks up the changes once the old threads have terminated.
As others have said there's no avoiding downtime for dB updates. Just pick a maintenance window where the site gets the least traffic and do it then.
The one about the fucking space hairdresser and the cowboy. He's got a tinfoil pal and a pedal bin
Well, I'm building a small web server for small business clients. Multiple sites on one Linode. My main concern is that while most of them will be glorified blogs, one client wants to venture out into the world of e-commerce sometime in the next year, and I want to do what I can to keep downtime minimal (if not 0) for updates if/when that happens.
Basically, just trying to future-proof myself now instead of kludging something together last minute.
Set the server up either with rocketeer or Capistrano and you'll be good to go. They both work on the premise that code is copied to a versioned folder on the server, composer, etc is run and then when everything is ready it'll switch a symlink from the last version to your current version and you'll be running live code. Followed by a graceful Apache restart which will restart the server so it picks up the changes once the old threads have terminated.
As others have said there's no avoiding downtime for dB updates. Just pick a maintenance window where the site gets the least traffic and do it then.
I'm assuming rocketeer or capistrano works with NGINX as well.
Anyone have any strong opinions on Xamarin vs React Native for a non-mobile developer? I'm leaning towards Xamarin because I prefer C# to JS (although I don't have heavy experience with either), but I'm willing to listen to anyone with experience either way.
Yes, I do: Don't do it. Abstraction layers in the mobile space are a sweet tantalizing fruit. Write one code base, deploy to multiple devices!
Then you realize the two major mobile OS's handle some major functions in vastly different ways and you end up needing a bunch of device specific knowledge and code anyway. Then you make the mistake of wanting to use a third party component that is popular on one device or the other and integrating it is a major pain in the ass. Then you realize most of your UI code ends up being 100% seperate anyway and the only thing your sharing is business logic and you could have just done that in C/C++ and not dealt with Yet Another Abstraction Layer (YAAL).
We have a Xamarin product at work that we are trying to unravel and re-write in native code (Swift and Java) because all the benefits of using Xamarin have long since faded away and now it's just in our way more than it's helpful.
Not sure if you are including React Native in that description or are you talking only about Xamarin.
React Native is not a single codebase, it simply supports both platforms and is a pretty good choice for mobile development as long as you are aware of the performance implications on the devices.
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
I think all abstraction layers over mobile code are a mistake. But I'll freely admit that is a hard line stance from being burned by our current stuff.
Having done native Android, Corona SDK, Cordova / Ionic, and React Native, native had the least hangups. Corona SDK actually wasn't terrible at the time (but I haven't touched it for 5+ years; it's not a great choice for most apps anyhow). Cordova / Ionic has been a pain every step of the way. React Native has been a pain for finding third party plugins with good cross platform implementations, but ~90%+ code sharing between platforms is doable.
Well, I'm building a small web server for small business clients. Multiple sites on one Linode. My main concern is that while most of them will be glorified blogs, one client wants to venture out into the world of e-commerce sometime in the next year, and I want to do what I can to keep downtime minimal (if not 0) for updates if/when that happens.
Basically, just trying to future-proof myself now instead of kludging something together last minute.
Set the server up either with rocketeer or Capistrano and you'll be good to go. They both work on the premise that code is copied to a versioned folder on the server, composer, etc is run and then when everything is ready it'll switch a symlink from the last version to your current version and you'll be running live code. Followed by a graceful Apache restart which will restart the server so it picks up the changes once the old threads have terminated.
As others have said there's no avoiding downtime for dB updates. Just pick a maintenance window where the site gets the least traffic and do it then.
I'm assuming rocketeer or capistrano works with NGINX as well.
Yeah, they should. The restart command is just passed through to the shell so presumably there's a nginx plugin or alternative.
The one about the fucking space hairdresser and the cowboy. He's got a tinfoil pal and a pedal bin
I love this image. I want to send it to all of the people who insist that I call our distributed computing projects (I run a corporate sponsored distributed computing network) "the cloud".
Having done native Android, Corona SDK, Cordova / Ionic, and React Native, native had the least hangups. Corona SDK actually wasn't terrible at the time (but I haven't touched it for 5+ years; it's not a great choice for most apps anyhow). Cordova / Ionic has been a pain every step of the way. React Native has been a pain for finding third party plugins with good cross platform implementations, but ~90%+ code sharing between platforms is doable.
I haven't heard anything good about Xamarin yet.
What did you find annoying about Cordova? We're leaning towards switching to Cordova at my job.
I'm not sure how many of y'all work with R or Pandas/Numpy in Python, but I'm having a...annoying issue in R Studio attempting to get plots to work.
You can see the workspace here. What the graph is supposed to look like is something closer to a large range of dots that should correlate positively when set to log scale (it's not set to log scale here but that doesn't change anything).
I'm not sure how many of y'all work with R or Pandas/Numpy in Python, but I'm having a...annoying issue in R Studio attempting to get plots to work.
You can see the workspace here. What the graph is supposed to look like is something closer to a large range of dots that should correlate positively when set to log scale (it's not set to log scale here but that doesn't change anything).
Any ideas?
probably plot fuckery is interpreting it differently than you'd like.
As an advanced beginner, I think ggplot is cleaner and easier to understand when you set it up.
Having done native Android, Corona SDK, Cordova / Ionic, and React Native, native had the least hangups. Corona SDK actually wasn't terrible at the time (but I haven't touched it for 5+ years; it's not a great choice for most apps anyhow). Cordova / Ionic has been a pain every step of the way. React Native has been a pain for finding third party plugins with good cross platform implementations, but ~90%+ code sharing between platforms is doable.
I haven't heard anything good about Xamarin yet.
What did you find annoying about Cordova? We're leaning towards switching to Cordova at my job.
Compared to actual native, UX and performance have been less than great. We had a rough time with getting an automated build process going, and it's still pretty fragile (plugin installs fail around every 5th build during one of Ionic's hooks into Cordova). We've had several bugs with the official plugins (the cordova in-app-browser plugin had input boxes that aren't focusable on android on occasion, or weird touch behavior if a page called element.focus() on iOS, or permissions not being asked for correctly in plugins on Android).
I shouldn't say it was a pain every step of the way. Initially it wasn't bad. Having a team already familiar with Angular, it made jumping into a mobile project much easier, and it might be a good choice for somewhat simple apps. This is also on Ionic 1; maybe the UX and performance is better on Ionic 2.
I'm not sure how many of y'all work with R or Pandas/Numpy in Python, but I'm having a...annoying issue in R Studio attempting to get plots to work.
You can see the workspace here. What the graph is supposed to look like is something closer to a large range of dots that should correlate positively when set to log scale (it's not set to log scale here but that doesn't change anything).
Any ideas?
probably plot fuckery is interpreting it differently than you'd like.
As an advanced beginner, I think ggplot is cleaner and easier to understand when you set it up.
Just been making our website not completely do _nothing_ on older devices / browsers.
It turns out that doing this for Blackberry is surprisingly okay; their emulator's fiddly to set up, but once it's going, you have web inspector and console logs and stuff. So I could find out that, yup, its implementation of javascript is too old and needs function.bind polyfilled and whatnot. I looked around and found polyfill.io, which seems like it'll do exactly what I want -- detect the right polyfills for your browser and magically supply them. Except that it didn't work when I tried it. Let's take a look at the docs, shall we?
Graceful degredation is something way too many developers don't even consider. It doesn't need to look snazzy on all platforms, but you should be able to get at least basic functionality out of it.
Graceful degredation is something way too many developers don't even consider. It doesn't need to look snazzy on all platforms, but you should be able to get at least basic functionality out of it.
I know there's some frameworks that do it for you, but I suspect best case scenario for a lot of people is duplicating work... which I can't see management being okay with.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Once I'd worked out there was no way this was going to work nicely, it was just a matter of showing _something_ rather than a blank page with errors in the dev console. Some things we want to fix properly, but pre-10 blackberries weren't going to get more than the minimum amount of attention.
You know those moments when you call someone over to ask about why something isn't working and then the moment you start explaining it to them you figure that shit out on your own.
I just had the same thing but with a really long post here.
So basically what I'm saying is thanks guys, you solved my problem by just existing!
Also C# events are not as simple as I would have expected!
You know those moments when you call someone over to ask about why something isn't working and then the moment you start explaining it to them you figure that shit out on your own.
I just had the same thing but with a really long post here.
So basically what I'm saying is thanks guys, you solved my problem by just existing!
Also C# events are not as simple as I would have expected!
Posts
Basically, just trying to future-proof myself now instead of kludging something together last minute.
Back in my old MySQL days we had that issue where db migrations would lock up large tables and take things down for a few minutes. I believe Postgres, at least more modern incarnations of it, are smarter and I have never run into such an issue.
The db migrations do still get us sometimes, though. We try to do commits and deploys which only have the schema migrations and in a way where the old code works with the new fields, then deploy the code which uses those new fields separately, then backfill data. It doesn't always work out that way, though, and we will sometimes get a hiccup where the migrations and code changes go out at the same time and then some server gets updated and restarted before the migrations have happened.
That could also be resolved by scripting our deploys more rather than just doing an all out opsworks deploy of everything. I've solved it on our amazon ECS based platforms by building a system which runs a task which does the db migrations first, when those complete successfully, then services are updated with the new code/images. I just need to build a similar thing for opsworks... but really I want to stop using opsworks anyway, for the most part.
That thing you're paranoid about happening? It happened. Why didn't you fix it in the first place if you're so paranoid?
You don't need to use JS with React Native. You can use Clojurescript or Typescript. I have never used the JS RN workflow, but the re-natal experience in Cljs is positively great. Unfortunately, I have no experience with Xamarin.
In the end, it's not a huge effort to try and use both and figure out which one you prefer, so you should probably sink the time and do so.
I made a game, it has penguins in it. It's pay what you like on Gumroad.
Currently Ebaying Nothing at all but I might do in the future.
I'm waiting for the day when I won't get yelled at for using virtual functions and can pass around std::functions.
i'm assuming your phrasing implies that you're trying to deploy a multi-platform mobile app?
i disagree with React, but in general you're better off with whatever you end up putting in your web view
Xamarin is a bad technology
Useful! No mention of a branch predictor in there - most research on other processors of that era using the ARM926EJ-S core indicate a lack of branch predictors. Branch prediction actually seems to be a more "recent" addition to the ARM family, to be honest.
Either way, I'm fine with removing the branches. It's an inner loop where I can provide branchless specialisations of the 2 common cases, which cover like 95%+ of all use cases, so I'm not too fussed. Gotta keep those pipelines fed!
Set the server up either with rocketeer or Capistrano and you'll be good to go. They both work on the premise that code is copied to a versioned folder on the server, composer, etc is run and then when everything is ready it'll switch a symlink from the last version to your current version and you'll be running live code. Followed by a graceful Apache restart which will restart the server so it picks up the changes once the old threads have terminated.
As others have said there's no avoiding downtime for dB updates. Just pick a maintenance window where the site gets the least traffic and do it then.
I'm assuming rocketeer or capistrano works with NGINX as well.
Yes, I do: Don't do it. Abstraction layers in the mobile space are a sweet tantalizing fruit. Write one code base, deploy to multiple devices!
Then you realize the two major mobile OS's handle some major functions in vastly different ways and you end up needing a bunch of device specific knowledge and code anyway. Then you make the mistake of wanting to use a third party component that is popular on one device or the other and integrating it is a major pain in the ass. Then you realize most of your UI code ends up being 100% seperate anyway and the only thing your sharing is business logic and you could have just done that in C/C++ and not dealt with Yet Another Abstraction Layer (YAAL).
We have a Xamarin product at work that we are trying to unravel and re-write in native code (Swift and Java) because all the benefits of using Xamarin have long since faded away and now it's just in our way more than it's helpful.
React Native is not a single codebase, it simply supports both platforms and is a pretty good choice for mobile development as long as you are aware of the performance implications on the devices.
I haven't heard anything good about Xamarin yet.
Yeah, they should. The restart command is just passed through to the shell so presumably there's a nginx plugin or alternative.
But the CLOUD will solve all our problems. The CLOUD is great. Join us in the CLOUD, Spawnbroker. Join usssssss.
I love this image. I want to send it to all of the people who insist that I call our distributed computing projects (I run a corporate sponsored distributed computing network) "the cloud".
One in a million is next Tuesday
What did you find annoying about Cordova? We're leaning towards switching to Cordova at my job.
You can see the workspace here. What the graph is supposed to look like is something closer to a large range of dots that should correlate positively when set to log scale (it's not set to log scale here but that doesn't change anything).
Any ideas?
probably plot fuckery is interpreting it differently than you'd like.
As an advanced beginner, I think ggplot is cleaner and easier to understand when you set it up.
https://docs.google.com/spreadsheets/d/1OLcAGbXhWIVcl5IziVpG0eKFJS3xi_Sac9kYMkRFvD8/edit?usp=sharing
Compared to actual native, UX and performance have been less than great. We had a rough time with getting an automated build process going, and it's still pretty fragile (plugin installs fail around every 5th build during one of Ionic's hooks into Cordova). We've had several bugs with the official plugins (the cordova in-app-browser plugin had input boxes that aren't focusable on android on occasion, or weird touch behavior if a page called element.focus() on iOS, or permissions not being asked for correctly in plugins on Android).
I shouldn't say it was a pain every step of the way. Initially it wasn't bad. Having a team already familiar with Angular, it made jumping into a mobile project much easier, and it might be a good choice for somewhat simple apps. This is also on Ionic 1; maybe the UX and performance is better on Ionic 2.
Ok I'll give that a look then, thanks
It turns out that doing this for Blackberry is surprisingly okay; their emulator's fiddly to set up, but once it's going, you have web inspector and console logs and stuff. So I could find out that, yup, its implementation of javascript is too old and needs function.bind polyfilled and whatnot. I looked around and found polyfill.io, which seems like it'll do exactly what I want -- detect the right polyfills for your browser and magically supply them. Except that it didn't work when I tried it. Let's take a look at the docs, shall we?
oh.
It's not like it's 1998.
Graceful degredation is something way too many developers don't even consider. It doesn't need to look snazzy on all platforms, but you should be able to get at least basic functionality out of it.
I know there's some frameworks that do it for you, but I suspect best case scenario for a lot of people is duplicating work... which I can't see management being okay with.
I just had the same thing but with a really long post here.
So basically what I'm saying is thanks guys, you solved my problem by just existing!
Also C# events are not as simple as I would have expected!
http://steamcommunity.com/id/pablocampy
There's an actual term for this!
https://en.wikipedia.org/wiki/Rubber_duck_debugging
I'm really not looking forward to the bug that's crossing languages and kernel/user space