alexpopescu

Bragging aside, explaining the whole business from a (potential) customer experience is what differentiates good from bad companies (_nb_ I was tempted to write successful vs failing, but then I realized there are some very bad companies out there)

> Maybe the ultimate solution is a personal wiki [...]

Maybe this: http://zim-wiki.org (haven't used it myself yet though)

I've never upgraded before, just started out fresh. But y env got pretty complicated so I'd like to try an upgrade. What's the experience with the "Fresh upgrade"[1]?

[1]: http://community.linuxmint.com/tutorial/view/2

Just (extremely curious): what's new about this new build system (except the Node.js dependency)?

I haven't read any of Zed's book and Amazon doesn't have a decent number of reviews, so I was wondering if someone could provide the shortest "why should I get this book"

thanks

Can you share what you store in each of the databases?

Here's what I'd speculate:

- Redis: message lists for active users

- Postgres: account details

- Cassandra: all messages

Thanks.

I use a bookmarking service (Pinboard) as I do for all pages I consider that I might need to get back to at some point. I also have the Pinboard archival service that saves a copy of the web page in case that goes away.

Do you accept visitors?

Everything's looking great... except the desks :-(

Beforing logging in, I'd really like to have an idea of what JellyReader is. The homepage looks good, but not as good as to show me what it is :-)

I think this is quite incorrect. I've recently got the new iPhone and looked at the possible options across AT&T, Verizon, T-Mobile (I haven't included Sprint for a reason I cannot recall right now).

If you calculate the costs over a 2 year span, the differences are quite significant: http://jots.mypopescu.com/post/61007400356/iphone-5s-choosin...

_nb_: I haven't included any interest/depreciation rates though.

That's exactly what I've been searching for!

Thanks for digging this up. I find the 2 models being almost identical. And as one can read in that thread there can be subcategories that one might consider.

My preference is still with the formulation Slava came up with:

1. it's slightly easier to think only about 3 buckets 2. category names are more descriptive 3. their explanation in the post makes them more approachable/easier to grasp than formulation in the Wikipedia page

I haven't read the book, nor did I know about Kano's model until today, so thanks again.

When talking about painkillers I think we should also think about how many have that pain. If it's too little, then that painkiller can be a distraction. So while I fully agree with you that a distraction is not a painkiller, the opposite is not always true.

Plus I think painkillers could definitely be just showstoppers.

Once again, I find this subcategorization working great as a refinement applied to the @coffeemug's model. The only point is not to start with it directly.

I have always wondered how many people use the stock Janus/maximum-awesome Vim setups? How do people maintain their customizations? (the same questions actually apply to other configuration systems like dotfiles, etc.)

The reason I ask is that I've found these projects absolutely great in helping me learn more, discovering new plugins, and putting them all together in a (somewhat) maintenable way. But I've ended up with my own forks. And while I only tweak them every 6months or so, I usually have a hard time rediscovering the improvements that these systems have made in the meanwhile.

I've recently tried adopting the http://www.bulletjournal.com/ system, but using Evernote. Unfortunately I wasn't able to make it work for me.

After just a few days I've found myself not being able to figure out at a glance what's next and having to go back and forth the notes. That even if I've spent the time to inter-link things. But at this point I should also mention that in my role (product manager) I have quite a few projects on my plate at all time and a month long list of things is usually in the high tens/hundred items (and doesn't include meetings).

I was really attracted by the BulletJournal system as it felt in a way similar to what I've been using, but with a nicer/cleaner visual representation. Basically I have my long list of things in a tool. Every Monday I spend a bit of time extracting what's the focus for the week into a separate file. In this file I also log daily activity. At the end of the week there's a short review and then I'm archiving the week.

> This is a picture of me in 2009, right around when I started Pinboard. I'm standing on a balcony in Botosani county, Romania, in the poorest county in the European Union.

I had no idea (based on his name) that Maciej started Pinboard in Romania.

Using git bundle looks like an interesting idea, but the solution suggested in the post is seems incomplete:

1. it's only working for master 2. it bundles everything making an update on a different machine more difficult

I'm pretty sure that people that use git bundle extensively know how to handle these scenarios though (I don't)

That's a very interesting subcategorization of game changers.

What I find quite interesting about thinking only in terms of hooks and painkillers is that this categorization might trick you.

A series of hooks could prove to be only distractions. A features that users think it's awesome is not necessarily "signing the deal". They might be an eye catcher, a conversation started, but in the end you might find that not enough users actually care about it.

As for painkillers, well, I think that those could be anything from game changers to distractions (include too many painkillers and you'll get MS Office :-).

Once again, this is only to say that I think I'd be thinking in terms of hooks and painkillers only after making sure that the feature is a game changer. And not vice versa.

ps: by the way I feel I disagree with some of the hooks you've listed. But that part of the discussion would fit better in a different context :-).

I think this is very much true considering Samsung's most (?) successful campaign lately has been focusing on the exact opposite message (Apple fanboys not knowing what's happening outside their world)

> Yeah, I thought about that, but it seems like you can only use them to get the "map" part of map/reduce... no aggregation. Unless I'm missing something.

I think that's correct.

How about "they should be an invitation to learn more about the system" :D? As far as I can tell, in many cases these defaults have almost never been reviewed by devs because most of the early users already knew what tweaks they needed.

Considering RethinkDB's secondary indexes can be defined around pretty complex ReQL expressions [1] you could already get some of it already.

[1] http://rethinkdb.com/docs/pragmatic-faq/#how-do-i-take-advan...

One aspect of micro-benchmarks that is most of the time ignored is that they reveal different default settings various systems come with. And unfortunately after seeing the results, not too many dig deeper to figure them out.

While both CouchDB and RethinkDB store JSON, the differences between them are more radical. I cannot post an as-extensive comparison as the one with MongoDB, but here are some aspects.

Please keep in mind that this is not an authoritative comparison and it may contain mistakes. Plus as for many such systems, the aspects covered are in reality not that easy to be described in just a few words.

Platforms:

- RethinkDB: Linux, OS X

- CouchDB: where Erlang VM is supported

Data model: - both JSON

Data access:

- RethinkDB: Unified chainable dynamic query language

- CouchDB: key-value, incremental map/reduce

Javascript integration:

- RethinkDB: V8 engine; JS expressions are allowed pretty much anywhere in the RQL

- CouchDB: Spindermonkey (?); incremental map/reduce, views are JS-based

Access languages:

- RethinkDB: Protocol Buffers

- CouchDB: HTTP

Indexing:

- RethinkDB: Multiple types of indexes (primary key, compound, secondary, arbitrarily computed)

- CouchDB: incremental indexes based on view functions

Sharding:

- RethinkDB: Guided range-based sharding (supervised/guided/advised/trained)

- CouchDB: -

Replication:

- RethinkDB - sync and async replication

- CouchDB - bi-directional replication can be set between multiple CouchDB servers

Multi-datancenter:

- RethinkDB - Multiple DC support with per-datacenter replication and write acknowledgements

- CouchDB - (?)

MapReduce:

- RethinkDB: Multiple MapReduce functions executing ReQL or Javascript operations

- CouchDB: views are map/reduce but they need to be pre-defined

Consistency model:

- RethinkDB: Immediate/strong consistency with support for out of date reads

- CouchDB: http://guide.couchdb.org/draft/consistency.html

Atomicity:

- both document level

Durability:

- both durable

Storage engine:

- RethinkDB: Log-structured B-tree serialization with incremental, fully concurrent garbage compactor

- CouchDB: B-tree

Query distribution engine:

- RethinkDB: Transparent routing, distributed and parallelized

- CouchDB: none

Caching engine:

- RethinkDB: Custom per-table configurable B-tree aware caching

- CouchDB: none (?)

What I wanted to suggest is that: at the tool level npm, gem, pip are simpler to get started. But I don't think that's the case at the env level where you'll need more tools.

So while I've used some wrong words in my comment, I was still (trying at least) referring to simplicity vs complexity.

PS: I've never been very fond of other complexities introduced by the maven approach, but that's a different (and probably longer) story.

Maybe these other systems are more fluid, but their are also a lot weaker in what their platform gives them. What I mean by this is that the Java world never needed the extra rvm, virtualenv, etc.

The complexity of dependency management doesn't come from declaring dependencies, but from managing conflicts over time and being able to create isolated environment.

Even if many call it the "jar nightmare", I don't know other systems that offer better isolation.

Lately if I see a post starting with "Unless you have been living under a rock", I stop reading.

I'm always impressed how such obvious tools (e.g. memcached, junit) can change the face of software development.

Do you have similar other obvious ones in mind? (please no rails :-)

Niiiice!