Thanks for the link! I think we'll have to add a new events table to track things like how long it takes to move from "Tasks" to "In Progress" to "In Review". It shouldn't be terribly challenging, and I love me some analytics.
Waffle does this I'm pretty sure, but we don't have it yet. It's on our roadmap though!
We've had the request for multiple repos on one Zube board when talking with PMs and consulting firms and we're aware that it's important for them. However, we're laser focused on making developers happy and they've told us that they care more about managing issues for a single repository, so we implemented that first.
Sure! It's a little hack that autoplays everywhere, browser and mobile. It's javascript that loops over numbered png images in the canvas tag. You can grab the js in the source of our homepage toward the bottom.
The process for creating the images is as follows:
Use quicktime to take a video, called demo.mov (or equivalent movie capture program with whatever file format)
Create a color palette from the movie
$ ffmpeg -i demo.mov -vf fps=10,scale=1378:-1:flags=lanczos,palettegen palette.png
Create a gif from the movie using the color palette
$ ffmpeg -i demo.mov -i palette.png -filter_complex "fps=10,scale=1378:-1:flags=lanczos[x];[x][1:v]paletteuse" output.gif
Create a sequence of pngs from the gif
$ convert -dispose Background -coalesce output.gif -colors 256 PNG8:target-%d.png
Yeah, we're a full web app and we love integrations (GitHub is just the first) so GitLab seems very promising. We haven't looked into the specifics yet but we'd love to create integration #2!
Waffle.io is good product and Zube is similar. We're both web apps that sync with GitHub issues. As far as functionality, Zube gives you some things that Waffle does not:
Comments - syntax highlighting; @mentions, emojis, issue reference autocomplete; live updating from GitHub comments for things like comment updates and deletes (so your data is consistent)
Cards - Commit references, events, and card references. Consistency of data, especially when multiple users are moving cards at the same time.
Boards - add and remove users from the board
Labels - create, update, and delete labels from a repo (not just a card)
Milestones - create, update, and delete labels from a repo (not just a card)
Zube also has many UX features that differ from Waffle like each user having their own row. Creating cards in any row/column. Dedicated views for each milestone.
Waffle has some features that Zube doesn't support right now like burndown charts and search. I'm not an expert on Waffle or anything so please correct me if I'm in error. It's kinda hard to know everything that a competitor does.
I don't think so, but I haven't fully explored it. I would love to implement it if I can. I know it's kind of a hack but your organization can whitelist 3rd party apps, which is probably a good idea if you have sensitive data.
Hey, Aaron here, cofounder Zube. We really hope it does! Zube makes it super easy to keep your cards up to date, even if some of the people on your team continue to only use GitHub issues. We'd love some feedback after you've had a chance to try it out.
Thanks for the insight. When I first started coding the tutorial I was really trying to minimize line count. I had originally wanted to write a post that said something like "Backbone only takes you 10 more lines of code", because that was what my gut was telling me. But when it became clear that I was not going to be able to get close to the same line count without doing exceptionally weird things, I thought better of it and coded the app like I normally would.
Your point is totally valid about some of the extra stuff I did. The one thing that irked me is that I added some lines because I didn't like the data structure, like the stuff in your example. In real life I would go change the data, but I felt like that might be slippery slope. For example if I changed the data for the phones show view I could have just done a loop over a 10 line template instead of the ridiculously long ~100 line template (although the Angular peeps could have also done the same thing).
In the end I decided to stick with the data provided by Angular and just massage it when necessary. It increased the line count and added complexity, but it made it feel like a Backbone app to me.
I'm in favor of using whatever framework fits your application the best. I would probably choose Angular if I envisioned hundreds of callbacks in Backbone.
Recoding the Angular tutorial is definitely going to favor Angular in parts. There are multiple times in the backbone-phonecat tutuorial where I had to write some code simply to make Backbone work slightly differently, and not necessarily any better. For example, case insensitive ordering.
Thanks for the link to the blog post. It raised an important point worthy of inspection. I ran some numbers and "peeking" after the first 1000 trials does change the outcome. The chance that the outcome will reverse from declaring branch A the winner with 95% confidence to declaring branch B the winner with 95% confidence is rather small, less than 10%. However, if you lower your requirements to 80% confidence then the chance of the winner swapping increases to over 50%! For reference, I used the Wilson approximation for binomial distributions. I'm sure the Wald approximation fares worse.
Weird... I always thought that if you are running a split test in parallel (all at the same time), then you can figure out the number of samples needed to compare the branches with statistical confidence. I mean it makes sense to me. As the number of samples increases for each split test the distribution shifts from a binomial distribution to a gaussian distribution by the central limit theorem, and that happens around 1000 samples with a reasonable conversion rate. Then you're just comparing Gaussians, centered around the mean conversion value, with a width proportional to the number of samples. Taking the difference between two gaussians will give you the "chance to be different". Standard practice is to wait until one branch has a 95% chance to be better and then declare it the winner. This will test for false positives, which is usually what you are concerned about. False negatives don't matter that much when it comes to things like picking a name.