tmail21

7 ms·

1.
by tmail21 9y ago
Actually we use React+mobx on both our web and RN stacks and it's been great. What we really like is that it is simple and extremely performant since in most cases it automatically updates only the React components that need to be re-r
2.
by tmail21 9y ago
Sure. Hyperledger Fabric 1.0 has the option of "Channels" to limit viewership rights. In particular it restricts rights to a subset of the community. For example, you may have a 1000 parties in the community, but a particular chan
3.
by tmail21 9y ago
The other major issue with Blockchain is that "all nodes can see everything". This is theoretically a problem with distributed databases as well. However, in the case of distributed databases, the database nodes that can "see
4.
by tmail21 9y ago
agreed. Although have encountered most of these ideas before, the goo analogy (whether valid or not) made everything easier to relate to. ps) Not a physicist.
5.
by tmail21 9y ago
I don't believe that one should try to create a single tool that covers both synchronous and asynchronous. Their UX is too different. It seems to me a better idea to create an asynchronous deep collaboration tool and integrate it with
6.
by tmail21 9y ago
Not sure about the governance model of Kotlin. Hopefully it succeeds.
7.
by tmail21 9y ago
Yes, but the resulting object is not a "List" and hence would not inter-operate with any function that took a List as input. In essence if the original object implements a List _interface_, then the new one should as well. If you
8.
by tmail21 9y ago
Cool. This needs to be built into the language or somehow standardized by the community. With lack of standardization of immutable collections, there would be lots of different ways that libraries would implement immutability. This would re
9.
by tmail21 9y ago
"Read-only" would not implement structural sharing. Consider the situation where you had a linked list with 10,000 elements and you wanted to return a new list with one new element added to the 'head' of the list. With
10.
by tmail21 9y ago
Looks like there is some distinction between Mutable, Read-only View and Immutable. According to this http://stackoverflow.com/questions/33727657/kotlin-and-immut... Kotlin does not support true immutability. For
11.
by tmail21 9y ago
What about immutability? A key part of functional programming is using immutable structures to avoid side effects. My understanding is that Swift has these to some extent ("let" vs "var", structs being immutable etc). An
12.
by tmail21 9y ago
How do you know for sure? :)
13.
by tmail21 9y ago
Agreed that all of these can be used asynchronously. However, I would refer to these as "incidentally-asynchronous", in the sense that their design goals were not primarily to be asynchronous (and hence support "Deep Work&quo
14.
by tmail21 9y ago
Ever increasing distraction and "real-time" communication and collaboration are reaching a point of diminishing returns and actually decreasing our productivity. The book Deep Work, by Cal Newport is a start on identifying the pro
15.
Slack Threads: A Missed Opportunity(tmail21.com)
2 points by tmail21 10y ago|0 comments
16.
by tmail21 10y ago
If one absolutely wants real-time collaborative editing then the only (long-term) solution I see is something like a deep learning solution that continuously semantically analyzes the merged state for semantic errors. In a particular proble
17.
by tmail21 10y ago
Yes, this problem could be mitigated somewhat by showing caret positions. But this method is very reliant on the users paying extremely close attention. It does not work at all when the silent semantic errors are caused by "far flung&q
18.
by tmail21 10y ago
It is fairly trivial to construct an example where editors are editing _different_ sentences and OT takes two locally semantically correct states and converges to a semantically incorrect (but grammatically correct) state. I think OT and ot
19.
by tmail21 10y ago
The basic problem with OT (and current "real-time" collaborative editing approaches) is that they can only achieve eventual consistency. While this sounds great, eventual consistency DOES NOT mean semantic consistency. This rules
20.
by tmail21 10y ago
The reason this is happening more and more is because teams are bumping up against the limits of synchronous communication. Especially when teams get large, and everyone has an expectation of immediate response the whole thing falls apart.
21.
by tmail21 11y ago
I wrote a follow up to both your article and the original one. https://medium.com/@rnotani/the-different-frustrations-of-sl... Here is a relevant quote from the article. "In my opinion both of these posts get it p
22.
The (different) Frustrations of Slack and EMail(medium.com)
2 points by tmail21 11y ago|0 comments
23.
The Biggest Pitfall of Slack and How to Overcome It(tmail21.com)
1 points by tmail21 11y ago|0 comments
24.
by tmail21 11y ago
Check out TMail21 ("Power Threads for Teams". It is explicitly designed as an asynchronous communication platform. Furthermore, it is being integrated into all of the chat services like Slack, Hipchat etc. to avoid balkanization b
25.
by tmail21 11y ago
The key is to realize that Slack et al are really good for synchronous communication (users need to be present simultaneously to really be effective). EMail was designed for asynchronous (reply later) communication. The expectation that eve
26.
by tmail21 11y ago
The other reasons why processes are not adopted is that most employees are not thinking in terms of 'processes'. Secondly typical process/BPM tools are geared towards I.T. rather than regular workers. Both problems can be sol
27.
by tmail21 11y ago
I apologize if they came across as excessively commercial. I thought they were relevant to the discussion at hand. I will be more careful in the future.
28.
by tmail21 11y ago
Thanks for your insights bitcuration. I agree that email is flexible enough to do things like goal oriented discussions, but it is just so painful. The best one can do is fling attachments around and hope to get all the versioning right and
29.
by tmail21 11y ago
You might want to consider TMail21 ( https://tmail21.com ). We just soft-launched a couple of weeks back. It is what we call a Lean BPM app. The idea behind TMail21 is that is starts with Topic-Oriented Discussions and then allows
30.
by tmail21 11y ago
You are right. There is a mix of notifications and discussions with the mix varying between the two based on the nature of user's communication. In more collaborative scenarios, it may be 80%-20% discussion-notification. In other scena

More ›