The time required to update changes across system - google-cloud-platform

Being inexperienced, there are many times where I am expecting changes to update shortly, if not immediately, but it doesn't. I end up spending a lot of time troubleshooting to no avail and it miraculously work later. I learned that it takes time for updates to propagate across system.
It has come to a point where many times I am unsure if it is because of the changes not propagated or because I have made a mistake. For example, I didn't know the load balancer takes hours to update and instead of waiting it out, I spent hours troubleshooting. I reckon it is good to have an idea of time required for each product/service to update? I searched the Google's documentation but can't seem to find much information.
I really appreciate any advice for new learner like myself to gauge the time required for certain products and services to update/propagate?
Thanks

Related

Redis for handling high-concurrecy and limited-capacity model?

I have a legacy system for managing courses at the university. Every half year, this happens:
limited capacity course (30 people) opens
1000 people trying to enroll in that course at the same time (literally waiting at computers to hit the "enroll" button at 8:00am sharp)
dozens/hundreds of courses like that, thousands of people in the system fighting for free slots at the same time
system goes down...
I wonder if Redis could help here. I cannot replace the legacy system (PHP based). I cannot spread the load either - all people have to have equal opportunity here.
My questions, please:
is Redis a good solution here?
Which data types and commands would you use for this use case? A rough outline of potential solution would be highly appreciated. I think it would be something with INCR but nor sure how to put it together with the rest.
Can this be realistically handler in (semi)real-time? i.e. if 1000 ppl hit the enroll button, 30 of them get the "yes" answer immediately, and the rest gets the "no" answer also immediately (matter of seconds, at most)
Thank you very much!

Background jobs occur very frequently and eat memory

I'd like to optimize my notification system, so here is how it works now:
Every time some change occurred on application, we're calling background job (Sidekiq) in order to compute some values and then to notify users via email.
This approach worked very well for a while, but suddenly we got memory leak as there were a lot of actions very frequently and we had about 30-50 workers per second so I need to refactor this.
What I would like to do is, instead of running worker immediately, to store it in array and perform bit later.
But I'm afraid that also will cause a problem, but just "delayed" problem.
I'm looking forward to hear more approaches and solutions as well.
Thanks in advance
So I found one very interesting solution:
I'm storing values to Redis directly as key - value, where the value is dataset with data I'd need later for computation. Then I'm using simple cron job, which occurs service which is responsible for reading data from Redis and computing them. I optimized Sidekiq workers to work only when cron is executed, everything works perfectly fine and even much faster then before.
I'm still eager to hear if there is any other approach/solution.
Thanks

OpenEdge 11.3 Application Migration

We have an application with 10 millions lines of code in 4GL(Progress) and a database also OpenEdge with 300 Tables. My Boss says we should migrate it to a new Programming language and a new Database Management system.
My questions are:
Do you think we should migrate it? Do you think Progress has a "future"?
If we should migrate it, how, are there any tools? Or should we begin with programming from scratch?
Thank you for the help.
Ablo
Unless your boss has access to an unlimited budget, endless user patience and a thirst for frustration and agony you should not waste any time thinking about rewrites.
http://www.joelonsoftware.com/articles/fog0000000069.html
Yes, Progress has a future. They probably will never be as sexy an option as Microsoft or Oracle or whatever the cool kids are using this week. But they have been around for 30 years and they will still be here when you and your boss retire.
There are those who will rain down scorn on Progress because it isn't X or it doesn't have Y. Maybe they can rewrite your 10 million lines of code next weekend and prove just how right they are. I would not, however, pay them for those efforts until after the user acceptance tests are passed and the implementation is completed.
A couple of years later (the original post being from 2014 and the answers being from 2014 to 2015) :
The post, which has gotten the most votes is argumenting basically two fold :
a. Progress (Openedge) has been around for a long time and is not going anywhere soon
b. Unless your boss has access to an unlimited budget, endless user patience and a thirst for frustration and agony you should not waste any time thinking about rewrites: http://www.joelonsoftware.com/articles/fog0000000069.html
With regard to a:
Yes, the Progress OpenEdge Stack is still around. But from my experience the difficulty to find experienced and skilled Openedge has gotten even more difficult.
But also an important factor here, which i think has evolved to much greater importance, since this discussion started:
The available Open Source Stacks for application development have gotten by factors better, both in terms of out-of-box functionality and quality and have decisively moved in direction of RAD.
I am thinking for instance of Spring Boot, but not only, see https://stackshare.io/spring-boot/alternatives. In the Java realm Spring Boot is certainly unique. Also for the development of rich Webui's many very valid options have emerged, which certainly are addressing RAD requirements, just some "arbitrary" examples https://vaadin.com for Java, but also https://www.polymer-project.org for Javascript, which are interestingly converging both with https://vaadin.com/flow.
Many of the available stacks are still evolving strongly, but all have making life easier for the developer as strong driver. Also in terms of architectures you will find a convergence of many of this stacks with regard basic building blocks and principles: Separation of Interfaces from Implementation, REST API's for remote communication, Object Relational Mapping Technologies, NoSql / Json approaches etc etc.
So yes the Open Source Stack are getting very efficient in terms of Development. And what must also be mentioned, that the scope of these stacks do not stop with development: Deployment, Operational Aspects and naturally also Testing are a strong ,which in the end also make the developers life easier.
Generally one can say the a well choosen Mix and Match of Open Source Stacks have a very strong value proposition, also on the background of RAD requirements, which a proprietary Stack, will have in the long run difficulty to match - at least from my point of view.
With regard to b:
Interestingly enough i was just recently with a customer, who is looking to do exactly this: rewrite their application. The irony: they are migrating from Progress to Progress OpenEdge, with several additional Open Edge compliant Tools. The reason two fold: Their code is getting very difficult to maintain and would refactoring in order to address requirements coming from Web Frontends. Also interesting, they are not finding enough qualified developers.
Basically: Code is sound and lives , when it can be refactored and when it can evolve with new requirements. Unfortunately there many examples - at least from my experience - to contrary.
Additionally End-of-Lifecyle of Software can force a company, to "rewrite" at least layers of their software. And this doesn't necessarily have to bad and impossible. I worked on a Project, which migrated over 300 Oracle Forms forms to a Java based UI within less then two years. This migration from a 2 tier to a 3 tier architecture actually positioned the company to evolve their architecture to address the needs of Web Ui's. So actually in the end this "rewrite" and a strong return of value also from the business perspective.
So to cut a (very;-)) long story short:
One way or another, it is easy to go wrong with generalizations.
You need not begin programming from scratch. There is help available online and yes, you can contact Progress Technical Support if you find difficulties. Generally, ABL code from previous version should work with only little changes. Here are few things that you need to do in order to migrate your application:
Backup databases
Backup source code and .r files
Truncate DB bi files
Convert your databases
Recompile ABL code and test
http://knowledgebase.progress.com articles will help you in this. If you are migrating from some older versions like 9, you can find a good set of new features. You can try them but only after you are done with your conversion.
If you are migrating from 32-bit to 64-bit and if you are using 32-bit libraries, you need to replace them with 64-bit
The first question I'd come back with is 'why'? If the application is not measuring up that's one thing, and the question needs to be looked at from that perspective.
If the perception is that Progress is somehow a "lesser" application development and operating environment, and the desire is only to move to a different development and operating environment - you'll end up with a lot of resources in time, effort, and money invested - not to mention the opportunity cost - and for what? To run on a different database platform? Will migrating result in a lower TCO? Faster development turn-around time? Quicker time to market? What's expected advantage in moving from Progress, and how long will it take to recover the migration cost - if ever?
Somewhere out there is a company who had similar thoughts and tried to move off of Progress and the ABL. The effort failed to meet their target performance and functionality metrics, so they eventually gave up on the migration, threw in the towel, and stayed with Progress - after spending $25M on the project.
Can your company afford that kind of risk / reward ratio?
Progress (Openedge) has been around for a long time and is not going anywhere soon. And rewriting 10 Million lines of code in any language just to use the current flavor of the month would never be worth it unless your current application is not doing what you need. Even then bringing it up to current needs would normally be a better solution.
If you need to migrate your current application to the latest version of Openedge (Progress) you would normally just make a copy of your database(s) and convert it/them to the new version of Openedge and compile your your code against the new databases and shake the bugs out. You may have some keyword issues, but this is usually pretty minor.
If you need help with programming I would suggest contacting Progress Software and attending the yearly trade show or going to https://community.progress.com/ and asking/looking for local user groups. The local user groups would be a stellar place to find local programming talent.
Hope this helps.....

Workaround for - graph api bug

Can anyone provide a workaround for this bug
Our app is managing a lot pages with many posts, but since 5 days ago we've had huge problems with that bug.
90% of our posts gain the above described error, 10% are working well.
After many hours of testing we know it's something about the "link" parameter.
Without it, we can post without any errors.
We tried to only post our images without the link parameter but after a hour of posting correctly we got a new error.
(#368) The action attempted has been deemed abusive or is otherwise disallowed. Interesting that posting an image without a link parameter is abusive.
We tried to regenerate all user_tokens and page_tokens but no success, the error still exists.
We tried to pause the service for 24 hours and start it again, no effect.
Does anyone have an idea or a workaround for this bug?
It doesn't seem that it was patched on Tuesday. Because of that we need a solution, we can't hold the service down for one more week.
the workaround from "thefreeman" works for me also:
add more admin(s) to the pages
generate tokens for the new admin
juggle the tokens to stay below limit
Limit per account (for me) seems to be about 150 posts per day.
Limit seems to reset at a certain point in time. Midnight at facebook?
(i am managing 60 Pages and posting roughly 200 updates per day.)
certainly not a nice solution, but the bugs in the fb-bugtracker don't seem to get too much attention :(
sometimes i get a new error: "OAuthException (#1500) The url you supplied is invalid".
Trying again later with the same data works though...

Implementing Expiration Dates in an application?

I'd like to put an expiration date in some software I made. Obviously
psuedocode:
if time() > xxx: exit()
All someone has to do here is set their system clock back. Anything better to do?
What would be more user friendly is to keep track of the number of days a user has used your software. For example, each time your program starts up you could write a date to an encrypted file (unless the date already exists in the file). Then once there are more than, say, 30 dates in the file, let the user know it is time to buy the full version.
Someone will always be able to defeat your system if they put enough effort into it. Joel Spolsky said something to this effect that is very accurate (words are mine):
Your software protection scheme does not have to be bullet-proof (nor can it be), it just needs to be good enough to keep the honest people honest
So, with that in mind we can think up something clever enough to keep the honest people honest as the filthy cheaters are not going to pay for your app anyway. I have never needed to do this, nor have I looked into any known methods, but I can think of a few ideas:
Use a two-way hash to store the initial date and compare that to the present date. You can save the has to disk.
On Windows, use the registry. Yes, this is no where near bullet-proof, but most people will not go digging through the registry to find your key (and most will not know how to anyway).
Use the created date of your installation files as a reference.
Work off of the create date of one of the files you install.
this gives you a non-changing date to subtract from now to get the time the program has been installed. The only problem with this is when they re-install it. The easiest way to combat this is with a registry setting.
There's no real solution here - anything can be cracked. You could consider:
checking the time with an online
service
storing the last run date and
checking to make sure that it isn't
after the current date
checking the
"last modified" date on some system
files.
What is your goal here? If it's to stop all theft, good luck with that; all protection schemes will be broken eventually. If it's to keep the honest people honest, don't worry about them setting the clock back - it's enough of a hassle that nobody will do it, and those honest folk will pay up immediately.
The solution doesn't need to be perfect, it just has to be annoying enough to the user so he won't try to game the system.
You could calculate the aboslute value's difference and make sure that it is smaller than X days. In that way, they would need to always keep their clock within X days. Which no one would ever do forever.
You can try to record the timestamps in the registry. You can encrypt the timestamps when you put them there. The question is is it worth it?
Messing with your computer clock, especially rolling it back creates all sorts of headaches. People usually do not do it, At least all the time - limited trial versions of software from Microsoft, Adobe, etc, do not try to build protection against rolling back the clock