Hacker Newsnew | comments | ask | jobs | submit | sidcool's commentslogin

They worked hard for that, didn't they?

reply

calinet6 16 hours ago | link

I'm tired of this "they worked hard for that" BS with acqui-hires and shutdowns.

Yeah, sure, they worked hard, but in the end they get a big fat F for the end result.

Services don't last forever, but I'm not gonna congratulate someone who runs around in circles for 3 years purporting to deliver a product of value, and then gives up when offered a better deal for themselves.

They didn't build a product, they built a nothing. It's like reverse vaporware, and I won't respect it.

reply

m3rc 16 hours ago | link

Yeah this is my main problem with the way "startup culture" seems to work. There's a lot of people in my university really pushing people to start their own businesses, but the general reasoning just seems to be "come up with something, advertise so that you get bought out, take the money". There's no emphasis on actually making anything, just on drumming up hype for an idea and selling that.

reply

ryandrake 12 hours ago | link

Well, if hype and vapor is what's getting bought, you might as well try to produce and sell it.

reply

m3rc 8 hours ago | link

And yeah, that'd be what I don't like about startup culture. I went into software development, not marketing.

reply

paulbaumgart 15 hours ago | link

They proved that they can build products. That makes them very valuable to companies with more money than time. It's a significant career success, if perhaps not quite a business success. And we can congratulate them for that.

reply

anon808 15 hours ago | link

sure, if the product they made wasn't depended on by people. these kind of acquisitions seem to always leave the product customers in a lurch. and for that we don't have to congratulate them.

reply

paulbaumgart 14 hours ago | link

Assuming this was a smart acquisition by Dropbox, they'll be able to create more value now than they were before the acquisition. Unless you're arguing that the acquisition is actually wealth-destroying, it seems pretty selfish to oppose it.

reply

anon808 14 hours ago | link

unless I was one of the customers who's out a service I depended on.

reply

sidcool 4 hours ago | link

I fully agree, may be the HackPad team wanted an exit and wanted to retire and spend all their earned money to live a hedonistic life. What's wrong with that?

reply

1ris 3 hours ago | link

It's like you worked hard, and then somebody pays you to stop trying.

reply

sidcool 4 hours ago | link

Yes, may be this project/product was a step towards a bigger aim they had. May be they wanted to build a SpaceX and started small to gain experience, capital and contacts.

reply

Einstalbert 15 hours ago | link

Agreed 100% It's like selling someone a rubber balloon. We're buying services and products, not party favors. We expect balloons to pop.

reply

karpodiem 16 hours ago | link

Yes!

reply

bambam12897 17 hours ago | link

Definitely! I'm just being realistic - These press releases are basically the tea ceremony everyone is expected to perform.

If you just made several mil I honestly doubt you're thinking about making the "transition as smooth as possible". You're thinking "should I buy a Lambo or a Ferrari?"

They probably got a memo from Dropbox saying "now that we own your ass, here is a press release that you'll publish asap"

reply

jmathai 14 hours ago | link

For something like this it's more like "perhaps i can put a down payment on a house after my stocks vest and i pay taxes".

reply

ryandrake 12 hours ago | link

A down payment on a house in the Peninsula is going to likely cost more than a Ferrari or Lamborghini

reply

monokrome 16 hours ago | link

Your assumption is not very realistic.

reply

pearjuice 16 hours ago | link

I don't know what Whatsapp, Instagram and the like their hourly rates are, but I doubt it adds up to the billions the got.

reply

sidcool 7 days ago | link | parent | on: Drop Dropbox

I appreciate your feelings towards the matter, but I don't support your action. An open letter to Drew Houston would have been enough. It's a corporation, we cannot force it to do something we want to. Boycotting them is not a good option.

reply

vdaniuk 7 days ago | link

Why it is not a good option to boycott them? I'd say this is a great option to putting pressure on a corporation.

reply

sidcool 7 days ago | link

It's almost like Socialism, where a populist sentiment is tried to be shoved down the throats of the corporations. I don't use dropbox, but I for sure appreciate their creative genius. It's their prerogative to appoint anyone they wish.

You might say it's your privilege to boycott, but then mass boycott is like mob mentality.

reply

vdaniuk 7 days ago | link

Are you being sarcastic?

reply

sidcool 7 days ago | link

Not really. Chasing Condi Rice throughout her life for what she did during her term as the Sec of state is uncalled for. If anything, she deserves a fair trial.

reply


Source?

-----

sgy 16 days ago | link

Outlook Web App: http://venturebeat.com/2014/03/31/microsoft-announces-outloo...

Coursera: I'm a beta tester

-----


I might be acting like a devil's advocate, but don't the metrics reflect user behavior? And it's perfectly fine if they tune their UI for revenue. They are not missionaries, but they are visionaries. They need money to keep the innovation going.

I am not a facebook fan or an affiliate, and I do resent few of their design decisions, but earning money is well within their framework of morality.

-----


The ugly side of capitalism. But that does not make the whole system bad. There are those who will always stall progress for profits, and there are those who will surmount the bullies. Go Elon!

-----


And this is the first step towards a country's gradual demise. World will always progress towards freedom. It's a gradual but sure process, just like evolution. Some call it Social evolution.

-----

sidcool 35 days ago | link | parent | on: How We Make Trello

So they create a new branch for each fix? And all developers are supposed to merge in their branch every few hours or so? Isn't it a bit of a drag?

-----

yen223 35 days ago | link

That's how I work as well. Not a huge problem if you're using git, since branches are cheap and merges are easy.

-----

sidcool 35 days ago | link

We use Subversion mostly, I guess that's why the merging is a hassle.

-----

tghw 35 days ago | link

In SVN, "merging" is a bad, scary, no good word. In Git/Mercurial it's an everyday operation that happens so seamlessly 90% of the time that you don't even notice. The other 10% of the time, you have great tools (i.e. 3-way merge tools) that make it easy to reconcile conflicting changes.

-----

erikpukinskis 35 days ago | link

I was confused about all your "we avoid merging" comments, because I can't imagine how you could possibly work without merging, but this explains it.

-----

karmelapple 35 days ago | link

Agreed. Amazing how much the right tool can change habits - for the extremely better. It has barely occurred to me that people might struggle with merges (at least, small feature merges) anymore. Switch to git at a minimum, if possible.

-----

dangoor 35 days ago | link

That's how we work on Brackets[1], and I think a lot of projects work that way. It depends what kind of version control system you use. It's pretty easy to do this with the "GitHub flow".

[1]: https://github.com/adobe/brackets

-----

dodger 35 days ago | link

Yes, more or less a new branch for each fix. But with git and Kiln, it's really not a drag at all; the merges are generally really easy and mostly performed by our release manager when the card makes it to 'Ready to Merge'.

-----

hiisi 35 days ago | link

Do I understand correctly that your stable 'master' branch is always ready for release? Basically it means that changes (fixes) should be relatively small, otherwise they are released via channels, correct?

-----

ssi1111 35 days ago | link

How do you test the fixes? Which branch gets deployed to the test environment?

-----

bobbygrace 35 days ago | link

Everyone runs dev environments locally and tests. A dev environment is really easy to set up with mongo and node. Occasionally, we’ll put stuff on a staging environment if we want to test a database or infrastructure change. Big, experimental client changes go to the alpha channel on production.

-----

ssi1111 35 days ago | link

So when you have 2 features/bug fixes in the same area, built in 2 different branches and deployed to isolated dev/test environments... the first time you might find out that they dont work well with each other is in Staging? Why wait for that when you could deploy to a common environment and catch issues sooner?

Btw... I am trying to get some teams in my company to get out of branching. So trying to understand your view (which is exactly what these teams are doing), hence these questions...

-----

bobbygrace 35 days ago | link

That rarely happens in our experience. With our internal board, we know who is working on what and in what area of the code. Plus, all code is reviewed by someone working in the same area.

-----

brown9-2 35 days ago | link

The alternative, having everyone work on the master branch, is a bigger drag, because it introduces all sorts of coordination problems like "is the master branch in a state to be deployed? are your changes done?".

-----

sidcool 35 days ago | link

You are right, that would be the opposite extreme. What we do is that we create a branch and push our code every few hours. After a preset time, the branch is merged with the level 2 branch for code review/testing/regression etc., and after that to the main branch and then released to live production.

This saves us some merging.

-----

brown9-2 35 days ago | link

Is merging painful enough for you team that it's worth avoiding?

-----

sidcool 35 days ago | link

It can't be avoided, but we do tend to try and minimize it.

-----

fishtoaster 35 days ago | link

My experience has been that maximizing merges works best. If you're constantly merging, hardly any of your merges have any friction. The longer you're separate from the master branch, the more likely you are to get painful merges with conflicts and subtle bugs.

-----

erichurkman 35 days ago | link

Elsewhere in the thread, you'll see that 'sidcool is on SVN, where merging is not a fun experience — which explains his team's aversion to merges.

-----

upops 35 days ago | link

On the Trello Android team we have a similar workflow to the web client and server developers. We merge in to a shared development branch when we have a complete feature or bugfix. With git's --no-ff this allows us to see when a new feature was implemented, and when bugs pop up we have a clear list of intersections where they could have been introduced. Our workflow is roughly based on an excellent post by Vincent Driessen, http://nvie.com/posts/a-successful-git-branching-model/.

-----

13hours 35 days ago | link

I'd love to hear more about the Android team's CI tools. What do you build with? What do you test with?

If you can build some kind of SaaS Android CI system, you'd probably make heaps of cash. Android CI is just enough of a pain to do yourself that people would pay for a one click type solution.

-----

hamidpalo 34 days ago | link

Another Trello Android dev here.

We use gradle for building. The actual app is split into two, trello-app and trello-lib. Anything that can be done w/o Android like SQLite caching, API calls, etc., is done in trello-lib which is a plain Java library. It makes the dev cycle much faster since you can write a unit test and run it in a second.

We don't have CI setup yet. For the server we use something custom but will most likely be moving to Buildbot and with that we'll also setup Android CI.

-----

hibbelig 35 days ago | link

With Subversion, you have a working copy with changes and then you do "svn update", and Subversion merges the upstream changes into your working copy. (But you don't normally call this merge.)

With Git, you have a working _repository_ with changes and then you do "git pull", and Git merges the upstream changes into your repository.

From the user's perspective, it looks about the same. But the Git merges are safer than the Subversion updates, because if the Subversion update messes up your working copy, you're stuck. But with Git, you always have (1) the commits you made locally, (2) the commits you just pulled from upstream, (3) the merge that was done by "git pull". And (1) and (2) can't get messed up, only (3) can get messed up. But you still have both your version (1) and their version (2) to go back to, so you have lots of chances to fix it.

Think of Git branches and the corresponding merges to be like Subversion updates with backups of the previous local working copy.

-----

kibibu 35 days ago | link

> Subversion updates with backups of the previous local working copy.

Which is a practice I got into the habit of doing manually when I used to work with Subversion.

-----

morganherlocker 35 days ago | link

I recently switched to this approach and it works very well. No more "I want to push out this quick fix, but I have to wrap up this other thing first so I don't break the build".

With github it is especially nice. I push to a remote branch, which I can see when I go to the project page. When I click merge it shows whether or not the TravisCI build passed. If it looks good, then I click to auto-merge and it's all set. It is possible to even automate away that part as well and have the whole thing merge and deploy on push if the build passes, but I am not quite ready to take the plunge yet with that (too easy to botch a production release IMHO).

-----

joshuacc 35 days ago | link

That's how my team at work does things as well. It actually speeds things along much more quickly than doing a bunch of fixes in one branch, because if one of your fixes is held up by QA, all the others can still be merged independently.

-----

grmarcil 35 days ago | link

Yep. My team follows a similar workflow with Github - every feature, bugfix, etc is developed on a branch off of master, then merged back into master via pull request when it is ready for deploying.

It's a nice workflow, changes are very visible to the entire team and well summarized (by the commit history and any comments/discussion on the pull request itself). Making a new branch is a one-line operation (two if you count hooking it up to the remote), so no, I've never personally felt that was a drag. Sometimes it feels a bit silly to create a branch for a one or two line fix, but the visibility to the team is worth it.

-----

sidcool 35 days ago | link

Developers in my team have quite a distaste for merging. We try to keep it at minimum. The trade off is less visibility. I agree with you.

-----

ssi1111 35 days ago | link

I agree. I would pick 1 dirty branch with continuous builds and tests any time over several branches. I have worked with several branches too and it is always messy, lots of confusion and too many overheads (including the Release Manager guy).

I love trello... but I don't like the branching model... :)

-----

odonnellryan 35 days ago | link

I love to hear about workflows, what's your ideal one?

-----

sidcool 35 days ago | link

What we do is that we create a branch and push our code every few hours. After a preset time, the branch is merged with the level 2 branch for code review/testing/regression etc., and after that to the main branch and then released to live production. This saves us some merging.

-----

ssi1111 35 days ago | link

Commit to 1 dirty branch; assume it is broken and let tests prove otherwise. When tests pass, you know it is a working branch, tag and release. I skipped a few steps for simplicity. Here, merges are an exception, not the rule.

This workflow won't work without automated tests... is lack of automated testing the reason to have individual branches for features and bug fixes?

-----


Honestly speaking, most of the jokes were pretty straight forward, and I am no genius or intellectual.

-----

spingsprong 36 days ago | link

I agree that most were pretty straight forward, but they were pretty funny. I especially loved joke 14.

-----


My guess would be that a sudden mechanical failure caused the plane to explode mid air, giving the crew no time to send a distress signal.

-----


I was hooked to the game and continued playing it for 2 hours non stop, AT WORK. It's addictive. I could not reach the magic figure, but the experience was great.

-----

More

Lists | RSS | Bookmarklet | Guidelines | FAQ | DMCA | News News | Feature Requests | Bugs | Y Combinator | Apply | Library

Search: