So, I have to make a minor bug fix to all of my scripts: I didn't realize there was a limit to the amount you could push into the Cache (BTW Google, I'm pretty sure this isn't documented anywhere).
Anyhow, so my three line fix resulted in my having to resubmit a bunch of scripts. Typically this isn't a big deal, Google is usually super awesome about approving them (usually the next business day). However, unfortunately they seem to be taking more time this time. This became a problem because I had to do a presentation today, and I just assumed they would be approved by now (I fudged it and just showed a spreadsheet with the script already installed).
So, I guess my main question here is maybe would have a more graceful upgrade process? It sometimes doesn't make sense to have the script removed from the gallery when waiting for approval.
Thanks!
Ben
I've opened an issue a while ago regarding this (nearly 2 years now). You probably want to star it to keep track of updates.
About the approval process, it is not "reliable" as you could see. I had scripts that took 3 months to be re-approved and then, the next upgrade, only a couple of days.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I have a decently popular Chrome extension, and yesterday I accidentally released a corrupted version of it, and didn't catch it for 10 hours. Within those 10 hours, the extension was updated for most users and I lost about half of them over the night based off of my Google Analytics reports (I had about 600 pageviews every 30 minutes, and now I only have 285). When I found out about my mistake I quickly reverted to an older version that works, but now, about 30 hours after an update that fixes the corruption, my pageviews are still the same.
My questions are:
Have I lost all those users or has it simply not updated for them yet?
If an extension is corrupt does it still check for updates or do the users have to press repair?
Any insight would be fantastic. As you can imagine, losing half your users over night because of 1 line of code is difficult to process.
What could have happened?
Well, this isn't a really clear situation, but, based on your information, there are a few possible scenarios:
Your users have uninstalled your extension because of this corrupt version. In this case (the worst one), it's pretty impossible to bring your users back, unfortunately.
Your "corrupted" version had issues with the update handling. For example issues with chrome.runtime.onInstalled to check the update and add new features, or issues with the Analytics part. This means that:
Your extension worked fine before the update.
It has been updated with a broken update handling function/method.
The new update (rollback to a working version) didn't solve anything, because your already corrupted extension is now unable to apply updates and/or send page views to analytics.
Your users disabled your extension in an attempt to narrow the issues (that's very uncommon, an edge case).
Your users didn't get the new update yet (which after thirty hours is also pretty uncommon).
What could you do?
Again, let's split the situation up:
In the first case, you cannot really do anything, unfortunately. That was a bad mistake! Learn from it and always test a thousand times before pushing updates.
Thinking about the second case? You should test your corrupted version on your machine, maybe using Chrome Canary to make things faster. This obviously means that you should have the previous versions stored somewhere; if you haven't got them, then it gets pretty hard, and for the future: always keep backups of your previous versions. Installing the old version, then manually updating to the corrupted one, and finally to the last one, can really help you understand what's going on. You should meticulously check the update method and see if there's something wrong.
Note: if you're not listening to chrome.runtime.onUpdateAvalilable and manually calling chrome.runtime.reload() to update your extension immediately, a Chrome restart may be necessary for it to update.
Just wait, although that's uncommon for this situation to happen, but this also is the only thing you can do in such cases.
Well, same as case #3.
If an extension is corrupt does it still check for updates or do the users have to press repair?
Well, there's no such thing as a "corrupted extension". Chrome will always check for updates (at least if the user didn't disable them in the chrome://flags), even if your extension is just a bunch of SyntaxErrors. Don't worry about this.
Extreme fix
In case that you're not sure about what to do, a re-design of your extension and a drastical purge from all the to-dos and bad practices is always a good thing. Just backup your previous version first, and start working on the 2.0 beta! Possibly, updating and improving the extension will bring much more users to it than just solving an existing issue. Personally, I almost always experienced an installation increase performing drastic restyles and re-writing better code from scratch.
I wish you to find the problem and bring your users back ASAP.
As you can imagine, losing half your users over night because of 1 line of code is difficult to process.
Yes, I do imagine. As an extension developer I really suffered for similar mistakes when I was learning update handling. So... well, break a leg! Wish you the best.
I am a Google App Script user since last 2 years. I see here in India during peak time i.e during evening the 1 minute trigger is not firing at proper time. Is there any server side issue or there is some other issue. Saying about the worse case scenarios, today my script trigger has not been fired since past 2 hours. I have correctly done logging. No log is printed means it does not even go to that method. Can anybody tell me what might be the exact reason behind it.
It might be beneficial to show us the code behind your script, given that there is a method that is potentially being skipped over. Have there been no errors thrown to you via the Google Apps Script notifications?
It seems, perhaps, your issue may fall into place with this currently reported error: https://code.google.com/p/google-apps-script-issues/issues/detail?id=2708
We're likely not going to be able to give you a precise answer to your problem if we can't examine what you're currently working with. I wish you luck in your endeavor, though.
I couldn't find any contact information, so I thought posting here would be the next best thing. I resubmitted an app last week (actually I've done it twice now in case there was some error) and I'm experiencing some problems:
1) the previous version of the app has disappeared from the gallery; and
2) it's taking a huge amount fo time (relative to my other experiences) to get it approved.
Who may I contact to follow up on this since it is quite urgent for our needs.
Many thanks,
Eamonn
There are occasionally delays in the review process for scripts being published to the gallery. If it takes a very long time (weeks) you may want to consider re-submitting the script.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I understand this question is on the edge of being acceptable for stackoverflow, but still, I feel it is worth asking.
I've started using bitbucket.org a couple of days ago, attracted by mercurial hosting, 1 free private repository, a wiki and an issue tracker. Just what I needed for my project.
I have to say, the features offered and the website's interface looks great, and I didn't have any problems with mercurial-related things so far. However, after these couple of days I am doubting if I should move somewhere else while it still easy (I haven't advertised the wiki page yet, etc...), because I am running constantly into minor and major issues:
Over these few days, I've noticed a lot of site slowdowns and a couple of timeouts
I find the wiki to be rather limited in features (apparently it is based on Creole Wiki, never heard of it before). It does not allow for, for example, right-aligning of images, borderless tables, etc. (well maybe it does, but the documentation doesn't tell)
I've noticed some bugs in the wiki (a TOC-generation macro issue was reported over a year ago, but still not fixed)
I've tried making my wiki public by changing the settings in the Admin panel, but it doesn't work.
some more wiki things [like inserting images is awkward, creating a new page isn't very obvious, internal linking has it's issues as well, .. ]
the sort order in the newsfeed was wrong when I pushed a multi-commited changset
It's very nice (and brave!) they have an publicly accessibly issue-tracker for bitbucket, but seeing a list of over 500 open issues (28 pages * 20 issues per page) doesn't give the impression they are taken care of as well as they could. At least some issues could have been moved to some 'will-not-consider' state. I am afraid my bug report about the private/public wiki page will still be in there within one year
The blog has a lot of post about 'downtimes'
Now, I don't want to be too hard on the people/company running bitbucket, since it isn't clear to me whether it is practically run by a single person (in which case it is truly amazing) or a well-run company (in which case it is not :-). Perhaps they have some growing pains... It is hard for me to tell.
So, what I am looking for here, is some experiences of other people with bitbucket, and advice if I should hold out, and wait until things improve (good chances for this?). Or not.
Jesper from Bitbucket here.
We're a pretty small team. In fact, most of the time, it's mainly me who does sysadmin/coding. This leaves very little time to develop new things, and sometimes, it doesn't even allow me to keep everything running smoothly (slowdowns/short outages always happen when I sleep.)
I realize this won't work in the long run, and something needs to be done. Therefore, I have decided to hire a bunch of people, mainly developers, but also a dedicated sysadmin and 1 or 2 UI guys (to make things prettier/more functional.) I'm currently wading through applications, and there are a lot of promising applicants in there.
Wrt/ stability, I've also provisioned 2 (much) larger instances from Amazon, where we do our hosting. We're throwing more money at this. I'm migrating a bunch of users/repositories to these larger instances today, and immediately following this, we will focus on making things faster as well.
Question was asked 2010, but I think this question needs a slightly more updated answer. I've been using Bitbucket for a few months now and as far as I can tell, it is an amazing git hosting system. You are provided with an issue tracker, wiki, unlimited public/private repositories, team collaboration, etc. Also, I have not yet encountered any downtime or slowness. On top of all of this, Bitbucket has an amazing UI, making navigating through source code and branches amazingly easy.
I would definitely recommend using this, and SourceTree.
I have not tested Bitbucket with really massive commits.
We have been using BitBucket HG for about six months, and I have little doubt but that we will move to a different VCS. It merges things badly, makes mistakes on complex commits, hurts our productivity. I don't know which parts are HG vs BitBucket, but I don't even have time to find out. Of course this is happening at the worst time, we have a do or die deliverable in two weeks.
I've been using BitBucket for a few years 1 year at my past employer and 2 years at my present employer.
It generally works fine without any problems. However, about once a month there will be some slowness. Over this particular week there were outages spanning multiple workdays where things were slow or we were unable to push our code changes for about an hour here or there.
So to summarize, most of the time it is reliable, but occasionally, about one day a month on average it is not reliable.
My coworkers and I were having a discussion about this yesterday. It seems that no matter how well we prepare and no matter how much we test and no matter what the client says immediately before the site becomes public, initial site launches almost always seem to be somewhat rocky. Some clients are better than others, but often things that were just fine during testing suddenly go horribly wrong when the site becomes public.
Is this a common experience? I'm not just talking about functionality breaking down (although that's often a problem as well). I'm also talking about sites that work exactly the way we wanted them to, but suddenly are not satisfactory to the client when it's time to make the site public. And I'm talking about clients that have been familiar with the site during most of the development process. Meaning, the public launch is definitely not the first time they've seen the site.
If you've dealt with this problem before, have you found a way to improve the situation? Or is this just something that will always be somewhat of a problem?
Don't worry. This is completely and entirely normal and happens with every piece of software. Everything that can go wrong will go wrong, and the most volatile entity in the development process, the client, will be the cause of these things.
You could do all the Requirements Gathering in the world, write a 100 page Proposal, provide screenshots and updates to the project hourly and the client will still not approve. On a personal note, I feel that the Internet is one of the worst mediums for this, as designs are a lot more free-flowing nowadays and the client will always have a certain picture in his/her mind; one that won't look like the finished product.
I find that a bulletproof contact with defined stages and sign-off sheets are the best way to handle such a situation. Assuming that your work is contracted you should ensure that at each stage the client is shown the work and is forced to approve each and every change made. At least that way if the client wants something changed you can tell them that they've already signed off that section and the additional work will cost them extra (also defined within the contract).
Not only did this approach work for me, it made the client stop and think about what he/she REALLY wanted. Luckily for me many of my clients are already tech-oriented, so they understand that these things can take time, but those that haven't a clue about Web Development expect things to be perfect within a couple of days. As long as you make sure that everything is covered in the contract the client will think about what they want and won't pester you with issues after.
Of course, anything you can do in regards to Quality Control would be fantastic and help the project move along nicely. Also ensure that some form of methodology is planned out before the project and that this methodology is known by the client(s). Often changes in fundamental areas can be costly and many clients do not seem to realise that a small change can require many things to be changed.
Yes, saw this several times on our projects (human beings are fickle).
Something that helps us in these situations is a good PM/Account Manager that can handle the customer, which makes things a little bit bearable on the technical level.
Web site launches are usually fairly smooth for us. Of course, we do extensive validation including code inspections, deployments to proto-servers (identical to our production servers), and mountains of documentation.
After every launch, we have a meeting to discuss what went well and what didn't so that we can make adjustments to our overall process and best-known-methods documents.
As for clients that change their minds at the last minute... sigh... we minimize that by having them sign off on the beta version. That way, there is no disagreement when the project is launched. If there is a disagreement, there is always a next release.
For what it's worth, the last site launch I did went off without a hitch. Now, it wasn't a high-traffic site, and there were some bugs that I did eventually fix, but there wasn't anything troubling on the day of the actual launch.
This was an ASP.NET/C# site. It wasn't terribly large or complicated, but it wasn't trivial either. Probably the most notable thing is that it was 100% designed, implemented, and tested by myself, from the database schema all the way up to the CSS. It was also my first time using ASP.NET. There were plenty of bumps in development but by the time I launched it I was pretty familiar with them and so knew what to expect.
I think the lesson to be learned from this is to have a good design up-front, solid implementation skills, and good testing, and a new site doesn't have to be a nightmare. There's at least a possibility of a trouble-free launch.
I wouldn't limit your statement to just web sites. I have worked on a lot of projects over the years and there are always details that get "discovered" when going live. No amount of testing removes all the fun things that can happen.
One thing I will say is what you learn in the first couple of hours of a new system going "on-line" is way move valuable that all the stuff learned during development. It's show time when the real cool problems and scenarios appear. Learn to love them and use these times as a learning point for the next time. Then each time it will be just at fun!
We used to have this problem a lot, but much less recently.
Partly for us it is about firmer project management and documenting the specification (as suggested in other answers here) but I believe more of the difference came from:
Expectation management - getting the client to accept that iterative changes are still to be expected after launch, that this is normal and not to worry about it
Increasing authority - we are now a well established (13 years) web developer and we can speak with a lot of expertise
Simply being more experienced - we can now predict in advance most of the queries that are likely to come up, and either resolve them, mitigate them or bring them to the client's attention so they don't sting us on the day
Plus, we rarely do big fanfare launches - a soft launch makes things much less stressful.
My experience is that web site launches are almost always rocky. I've only had two exceptions to this common truth. The first was a site developed for a small business ran by one person. This went smoothly because, well there was only one person to please so is was fairly easy to track what they wanted. The other was a multi-million dollar website launched by a fortune 500 company. This happened to go smoothly because there were 2 PMs and a small army of consultants there to manage the needs of the customer. That coupled with a one month of straight application load testing and a 1,000 user beta launch meant when the site finally went "live", I was able to get a full nights sleep (which is fairly uncommon). Neither of these situations constitute then norm though. Of course, there's nothing better than several thousand beta testers hitting your site to help find those contingencies that you never thought of.
I'm sure you can figure out the kind of errors that always sneak in, so for example is it due to rather superficial testing? E.g. randomly clicking around and checking if things appear to be right.
In order to improve I propose something along the following:
Create documents/checklists that specify all testing procedures.
Get regular people to test, not just the folks who built the application.
Setup a staging environment which closely resembles production.
Post-launch, analyze what went wrong and why it went wrong.
Maybe get external QA to check on your procedures.
Now, all those suggestions are of course very obvious but implementing them into your launch procedures will require time.
In general this really is an ongoing process which will help you and your colleagues to improve. And also be happier, because fixing bugs in production just makes you age rapidly. ;-)
Keep in mind, you won't be done the first time. Documents are heavy which is why people don't read them. People are also lazy and don't follow the procedures. This means that you always have analyze what happened, go back and improve the procedures.
If you have the opportunity I'd also spend some time on looking why nothing went wrong with another launch and comparing this to the usual.