I attempted to add another dispatch domain to a Kynetx app yesterday and could not get the app to fire on the new domain. I've seen some lag on domain updating before (usually limited to an hour or so), so I decided to wait a day and see if it updated.
After about 24 hours, the app still will not fire on the new domain. So, I removed a domain that had been in the app for a while to make sure I was not me making a typo (if it was a typo, the app would update correctly and would not fire on the removed domain). Unfortunately, it still fires on the domain that was removed.
So now the app fires on a domain not listed in the dispatch{} section, but doesn't fire on one that is listed. I have tried the testing version of the app and the production (deployed) version, but both have this same problem.
Any ideas? Anyone know of downtime with Kynetx's dispatch domains server?
Update: the app also fires on a google search to annotate the results from the same domains in the dispatch. This is also not working. I have added a few more domains, and the app does not fire on any of them.
Update:
select statements:
select using "google.com|bing.com|yahoo.com" setting()
for the search annotation
select using ".*"
foreach datasource:spreadsheet("&sq=domain%3D" + page:url("domain")).pick("$.feed.entry") setting (site)
for rule that fires on that domain.
Keep in mind, I didn't make any changes to the select statements or rules.
New domains I added, to both the spreadsheet datasource and the dispatch domains:
3flamingosyogurt.com
massageenvy.com
abcapartmentsolutions.com
worldsoffun.com
Long story, short: The Google Doc datasource had been set to not republish itself upon updating.
There were other complicating factors, but I'll leave those out for now :).
Moral of the story is always republish your datasources.
Related
I have a cool flutter app which is used to track staff attendance. A user can check-in and check out when they start/stop working and the app record that event, calculate the number of hours worked and send a weekly summary to the manager of the staff expected wages. The current problem is that some staff members forget to check out (everyone is ok with check-in) so we don’t have good numbers and we need to manually change the attendance. I would like to add something to remember them to check out, and I am looking for creative ideas to do so. My objective is to make something very affordable.
So far I thought about two options:
to use geolocation and track when staff get in/out of a certain location and log it as check-in and check out
to set a timer when they start the shift and send a local notification if after xx hours they have not done the checkout
Geolocation seems to be the best because I can even automate the checkin/check out and do it in the backend but it will consme lots of resources in the client because I would need to check their location every while even when their at at home or on holiday...
The timer has some limits and still, I would need to manage background tasks that are complex as well as imprecise checkout depengin on when the notification goes out.
Do you have any suggestions on anything simple to implement?
I would suggest the second option.
A simple scheduler which would look for all the employees who are checked in for more than x number of hours and then throw a clickable notification to checkout. It would be an easy and clean solution. However, it has several limitations as an employee might leave early but checkout later.
In my opinion, Your most clean solution would be to have an RFID/NFC check which automatically registers as a user checks out from the building.
Another thing that can be done if your employees are working mostly on their computers. There can be a browser extension or a web app which will clock in the time they are working on their laptops. Once they close it they will be automatically checked out.
I'm trying to create a simple order using transactions API on actions on Google, for this, I'm using this sample app, but when I try to place the order, the device times out, instead of showing the receipt details. The weird thing is that this code gets executed (I added some logs locally to make sure).
Has anyone been able to run this sample app successfully? I already enabled the actions on Google API on my project on Google cloud, so I'm not sure what I'm missing here.
First, you got to make sure you have enabled transaction support for your app.
If you are testing on the simulator, disable Sandbox mode (checkbox on top right).
Sandbox ensures that any transactions or orders made during simulation are fake
I've ran into this issue before.
You have to keep in mind that the Order ID gets tracked so it needs to be different every time you run the app. That is why I decided to use a UUID time stamp function to make sure the Order ID will be different every time.
I'm referring to wherever it mentions 'UNIQUE_ORDER_ID' in the code. Once you take care of this issue, you will see the receipt every time you run the demo.
We have an app that is written in PHP. The front end uses javascript heavily. Generally, for normal applications that require page reloads, continuous deployment is not really an issue, because:
The app can be deployed with build tags: myapp-4-3-2013-b1, myapp-4-3-2013-b2, etc.
When the user loads a page (we are using the front controller pattern), we can inject the buildtag and the files are loaded from the app directory with the correct build tag.
We do not need to keep the older builds around for too long because as the older requests finish, they will move to the newer build tags.
The issue with database and user data being incompatible is not very high as we move people to the newer builds after their requests finish (more on this later).
Now, the problem with our app is that it uses AJAX heavily for smooth page loads. In addition, because there is no page refresh at all when people navigate through the application, people can keep their unsaved data in a their current browser session and revisit it as long as the browser has not been refreshed.
This leads to bigger problems if we want to achieve continuous deployment:
We can keep the user's buildtag in their session (set when they make the first request) and only switch to newer buildtags after the logout and login again. This is obviously bad, because if things like the database schema changes or the format of files to be written to disk changes in a newer build, there is no way to reconcile this.
We force all new requests to a newer build tag, but there is a possibility we change client side javascript and will break a lot of things if we force everyone with a session onto the new build tags immediately.
Obviously, the above won't occur with every build we push and hopefully will not happen a lot, but we want to build a fool proof process so that every build which passes our tests can be deployed. At the same time, we want to make sure that every deployed and test passing build does not inadvertently break in clients with running sessions cause a whole bunch of problems.
I have done some investigation and what google does (at least in google groups) is that they push a message out to the clients to refresh the application (browser window). However, in their case, all unsaved client side data (like unsaved message, etc) would be lost.
Given that applications that uses AJAX and local data are very common these days, what are some more intelligent ways of handling this that will provide minimal disruption to users/clients?
Let me preface this that I haven't ever thought of continuous deployment before reading your post, but it does sound like quite a good idea! I've got a few examples where this would be nice.
My thoughts on solving your problem though would be to go for your first suggestion (which is cleaner), and get around the database schema changes like this:
Implement an API service layer in your application that handles the database or file access, which is outside of your build tag environment. For example, you'd have myapp-4-3-2013-b1, and db-services folders.
db-services would provide any interaction with the database with a series of versioned services. For example, registerNewUser2() or processOrder3().
When you needed to change the database schema, you'd provide a new version of that service and upgrade your build tag environment to look at the new version. You'd also provide a legacy service that handles the old schema to new schema upgrade.
For example, say you registered new users like this:
registerNewUser2(username, password, fullname) {
writeToDB(username, password, fullname);
}
And you needed to update the schema to add the user's date of birth:
registerNewUser3(username, password, fullname, dateofbirth) {
writeToDB(username, password, fullname, dateofbirth);
}
registerNewUser2(username, password, fullname) {
registerNewUser3(username, password, fullname, NULL);
}
The new build tag will be changed to call registerNewUser3(), while the previous build tag is still using registerNewUser2().
So the old build tag will continue to work, just that any new users registered will have a NULL date of birth. When an updated build tag is used, the date of birth is written to the database correctly.
You would need to update db-services immediately, as soon as you roll out the new build tag - or even before you roll out the build tag I guess.
Once you're sure that everyone is using the new version, you can just delete registerNewUser2() from the next version of db-services.
This will be quite complicated to make sure that you are correctly handling the conversion between old API and new API calls, but might be feasible if you're already handling continuous deployment.
There's a lot of events happening all the time on my university campus, and, together with a few other students, we thought it would be nice to provide the event schedule as a calendar. So organisers register their event on the intranet, and it gets added to an icalendar file which people on the campus can subscribe to.
This works great when people load the calendar url on their iPhones, but it doesn't when loading in Google Calendar. We have noticed two problems:
When you subscribe to the calendar and then log out and back in, events are no longer visible. Sometimes, clicking refresh fixes it. The vents do not disappear from android devices associated with your account.
When an event is removed from the icalendar file (eg. if it's cancelled), it still remains on the android devices that sync with any google account that subscribed to the calendar. New events sync fine, though, so it's not that the sync didn't happen.
Do you know how I can solve these two problems? I've noticed the STATUS:CANCELLED property in VEVENTs, but it doesn't seem to work when the calendar method is PUBLISH.
Thanks!
PS: If you can suggest a way to test changes faster that waiting for Google to pull the changes from the server, it would be great; right now, I have to wait about 6 hours between each test...
my understanding is that removing it from the file is not the way to cancel an event. One must ensure that there is a UNIQUE identifier to match any changes.
Also must follow the spec for cancelling/changing an event.
See How to cancel an calendar event using ics files?
If all of that is correct, then the various applications that 'subscribe' to a calendar should in theory update the event status when they read the updated file. Unfortunately the speed and frequency of that is up to that application. (NB: note also difference between subscribe and "import")
Yes I have noticed that google is slow to update sometimes. Only thing I can think of is use another application where you have control perhaps over the subscription update frequency to test if the way that you are cancelling an event is working. Once you see the cancellations happening there, then resume testing on google (I have noticed Google is more pedantic than some apps, so you may still have to work to get it 100% working on google.)
Hope that helps!
I've tried the suggestions but Google Calendar only ever adds another event. The iCalendar validators say that the files I generate are valid, and iCal on the Mac removes an event if it has cancel information. But neither Google Calendar or Outlook do. Rather frustrating.
So as to avoid overwhelming the infrastructure in a web application instance, what would be the methods of implementing a feature roll out to a controlled group of your user-base?
It depends on the situation. You can't really redirect them to another site using another database if the users are expecting to work with real data and the real site.
I would introduce a flag on your users in your user-table, let's say isBetaUser (bool). Then you can just show these new features for users that got this flag set to True. You could also let them check this flag off using a checkbox through some settings page, if they don't like the idea of trying out new features that is.
Partition your users into groups. Randomly. Demographically. Somehow.
Pick one or more groups for a pilot.
Fix your web site to have both versions of your app running. Maybe use virtual hosting or a different path or something.
One database. Two applications. Data doesn't move. Only the presentation changes.
At first, all users are in the old version. Workload has not changed.
Move a group of users so that their default URL's or links or menus or whatever are references to the new application.
Same workload. Same database. Same number of users. Two applications.
Move another group of users to the new application.
Same workload. Same database. Same number of users. Two applications.
Eventually, after all users are moved, you can delete the old application.