Link Dumps

[simontegg]

http://lowrekey.github.io/fourd.js/ https://developers.google.com/chart/interactive/docs/gallery/orgchart http://techcrunch.com/2015/04/28/facebook-api-shut-down/?ncid=rss#.pnrnmr:NEcQ

[simontegg]

http://99designs.com/designer-blog/2014/01/15/7-unbreakable-laws-of-user-interface-design/

[simontegg]

https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html

"Because of multiple round-trips and over-fetching, applications built in the REST style inevitably end up building ad hoc endpoints that are superficially in the REST style. These actually couple the data to a particular view which explicitly violates one of REST's major goals. "

[simontegg]

Alan Kay on messaging: http://c2.com/cgi/wiki?AlanKayOnMessaging

Hacker News discussion on Diaspora's 0.5 release: https://news.ycombinator.com/item?id=9482469

[simontegg]

Compare and contrast: Rich Hickey - Hammock driven development Peter Hintjens - Simplicity Oriented Design Mary Poppendieck and Tom Poppendieck - Lean Software Developent Audrey Tang - Optimise for fun

[ahdinosaur]

http://www.slideshare.net/alvarosanchezmariscal/stateless-authentication-for-microservices

[simontegg]

http://sahandsaba.com/nine-anti-patterns-every-programmer-should-be-aware-of-with-examples.html

[simontegg]

http://bigeng.io/post/118399425343/why-the-way-we-look-at-technical-debt-is-wrong

[simontegg]

Hacker news on "the failure of agile"

https://news.ycombinator.com/item?id=9538858

[simontegg]

interested in your take on this one @ahdinosaur @joshuavial http://martinfowler.com/bliki/MicroservicePremium.html

[simontegg]

http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html Martin Fowler's original take on micro-services http://martinfowler.com/articles/microservices.html

[ahdinosaur]

@simontegg i agree that microservices have a cost, which is why i started Holodex as a monolith and would recommend doing so for any project in the 'make it work' phase of development. the problem is that the longer a project remains a monolith (especially if it increases scope to include any dependency services), the harder it is to split out later. an open question that was brought up in the articles is 'what's the right size of a microservice?'. should Holodex be one service, many services? and that's not even mentioning the question of Holodex's scope.

the approach i'm taking by intuition: clearly define the scope of the project, start building a monolith to solve this scope, then as things start to work split things out into re-usable modules and eventually de-coupled services, and if your scope ever requires another scope (Holodex will soon require authentication (who you are) which i've defined as out of scope for Holodex) please take the extra effort now to add it in a somewhat de-couple'd way as otherwise it's gonna be much more expensive to de-couple later, plus it's best for the ecosystem as a whole to have more re-usable services for common app dependencies.

that's a bunch of rambling, does that help at all @simontegg?

[ahdinosaur]

in the broader app ecosystem perspective, i'm okay if an app is grossly monolithic the first time some problem is solved (e.g. Loomio which is (should be?) scoped to discussions and decisions but also includes authentication, user profiles, groups (admins, memberships, invitations, profiles, child groups), notifications, etc.) but when it's the second time around (e.g. Cobudget which is (should be?) scoped to group crowdfunding but also includes authentication, groups (admins, memberships, invitations)) i find it harder to swallow, as i reckon that's when we should be putting in the extra effort to make the solution re-usable and de-coupled so that we solve the problem for good, not just until we want to build another app.

[simontegg]

http://www.slideshare.net/neo4j/raph-visualization-unpicking-the-hairball-joe-parry-graphconnect-london-2013

[simontegg]

http://www.inf.uni-konstanz.de/gk/pubsys/publishedFiles/NoOrBr14.pdf

[simontegg]

In the cases of parallel development of inter-dependent software modules set up a negotiation table to solve conflict between the development teams.

http://www.upedu.org/papers/ICSE2015_OrganizationalFactors/LavalleeRobillard_ICSE2015_WhyGoodDevelopersWriteBadCode.pdf

[simontegg]

I think there are a lot of conflicting ideas at play here. As a coder, yes I can write good code. But however, everyone I know in the valley tells me "just shut up and launch, it doesn't have to be good. You should have launched yesterday, that's what they would have told you at YC". This advice have a lot of truth to it, because you need to get feedback, validate your project, and perhaps have the first-to-market advantage in the highly competitive world of technology today, with investors and customers hounding you on both sides. However, this hasty, rushed culture necessarily will result in a lot of poorly-written code being deployed (followed by a lot of rewrites), even by decent coders, because they simply aren't given the time and runway. reply

The situation is very different when creating software for internal use in large corporations, which I think was the case with this study. With a startup, launching early can get you the advantages you mentioned, and your code quality does not necessarily have to be high because you generally will not have many users at the start. Large internal software must be highly functional and performant from the first deployment because it will immediately be used by the whole company and will often affect revenue streams. This allows low quality to have a huge impact from day 1.

https://news.ycombinator.com/item?id=9565218

[simontegg]

http://hepburndata.blogspot.co.nz/2011/12/perspective-is-everything-why-even-most.html

[ahdinosaur]

http://makerbook.net : hand-picked directory of the best free resources for creatives.

[ahdinosaur]

from @simontegg, http://conceptviz.github.io/#/e30=

[ahdinosaur]

http://zguide.zeromq.org/page:all#Chapter-The-ZeroMQ-Community

[simontegg]

With ZeroMQ, we said we were going to make "the Fastest. Messaging. Ever.", which qualifies as a good motivator. If we'd said, we're going to make "a smart transport layer that'll connect your moving pieces cheaply and flexibly across your enterprise", we'd have failed

Then your work must be beautiful, immediately useful, and attractive. Your contributors are users who want to explore just a little beyond where they are now. Make it simple, elegant, and brutally clean. The experience when people run or use your work should be an emotional one. They should feel something, and if you accurately solved even just one big problem that until then they didn't quite realize they faced, you'll have a small part of their soul.

Oh, yes

[simontegg]

I think this is going to be important now and in the future. Systems are getting so complex nobody can build something complete from scratch. I see people making high quality components and then merging or being acquired to create a whole end user product. Prior to that point, you'd have something that's not very profitable unless lots of companies license your component and do integration themselves.

So, an interesting thing I observed while building a SaaS company was that you can actually get off the ground with a very simple solution, you'll just end up serving smaller customers with relatively simple needs (say $50-100/mo.) These initial folks will pepper you with feature requests while still paying you money for what you've got, which can give you feedback about which complexities you're missing that you really need to implement. If you choose which things to implement carefully, you end up making your product more useful to larger customers and you'll start closing some larger deals. (E.g. $500/mo.) Rinse and repeat and before too long you've got a product with all the bells and whistles and you're closing enterprise deals. (E.g. $2,500+/mo.) The numbers here are all relative, but the point is that the smaller customers end up subsidizing the development of what becomes an enterprise product. (I think the advantage this approach has over the one you've suggested is that the product is always capable of making money even from the very beginning, just on a smaller scale at first. I think this is a critical feedback mechanism so that folks know whether what they're developing is actually useful to folks.)

https://news.ycombinator.com/item?id=9589202

[ahdinosaur]

from Ants, ‘the future of work visualisation'. note the pricing is $13/user.

[simontegg]

http://www.coppelia.io/2012/06/graphing-the-history-of-philosophy/

[simontegg]

via @rdbartlett

Yeah I wanted to track plans vs reality. Now I have come to terms with the fact that I hate plans. Agreed objectives + high communications + small tasks suits me much better. Seems much more efficient to invest in making people feel nice at work than it does to invest in highly detailed plans and roles and tracking

However I am revealing my 'full timer' privilege. People working multiple simultaneous contracts can't play it quite like that usually

[rdbartlett]

Yeah I keep re-learning over and over: information scarcity is the justification for command and control hierarchies >> information abundance creates opportunity for nonhierarchical organisation >> but it only works if you actually do the information abundance bit!!

[simontegg]

http://www.kennybastani.com/2015/05/graph-analysis-microservice-neo4j.html

[simontegg]

http://rhiever.github.io/redditviz/clustered/

[simontegg]

https://github.com/stuarthalloway/presentations/wiki/Narcissistic-Design

[simontegg]

http://www.theguardian.com/business/2015/may/30/bring-back-boss-class-holacracy-zappos

[simontegg]

https://github.com/Flipboard/react-canvas http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/

[simontegg]

http://andrewchen.co/the-next-feature-fallacy-the-fallacy-that-the-next-new-feature-will-suddenly-make-people-use-your-product/

[simontegg]

Be good if ssb was this easy http://zeronet.io/

[simontegg]

woah @ahdinosaur http://www.ribbonfarm.com/2015/05/28/the-amazing-shrinking-org-chart/

[simontegg]

The process makes the underlying social reality simpler and more legible of course, but not entirely, or even primarily, in service of function. A good deal of the process is about imposing anxiety-alleviating platonic structural beauty.

There are two basic (but not mutually exclusive) responses you can have to this phenomenon of shrinking org-chart views of corporate realities: turn to more powerful maps or step back and reconsider what sort of situation awareness you actually need in order to be effective.

[simontegg]

In emerging stream corporations, running on Slack instead of email, staffed in opt-in ways, and invisible ecosystems on Github and social media activity backing up visible tip-of-the-iceberg engineering and marketing operations, org charts are a museum technology. Fluid role definitions and transient relationships states matter more than nominal boxes and reporting relationships. For a stream corporation, an org chart is increasingly a not-even-wrong construct for thinking about corporate anatomy. Because most of the structure is not formally created or under deterministic control.

[ahdinosaur]

nice find @simontegg :smile_cat:

[simontegg]

Example of a nice visual UI http://gitup.co/

[simontegg]

The importance of a product architecture (not technical architecture) for achieving great design https://medium.com/@intercom/the-dribbblisation-of-design-406422ccb026

[simontegg]

http://insomanic.me.uk/post/48136679276/looking-back-at-7-years-with-my-startup

I still believe a place exists for GroupSpaces or a similar service to scale to serve the market of the millions of membership organisations that currently rely on the unhappy marriage of a Yahoo/Google Group coupled with an Excel spreadsheet/google doc for member records, in addition to their own website and other services for events or payments.

[ahdinosaur]

ipfs weekly open development sprints: https://github.com/ipfs/pm, example sprint: https://github.com/ipfs/pm/issues/11

[ahdinosaur]

SaaS Questions: The most important questions every SaaS company should have answers to.

[ahdinosaur]

data-ui: a collection of modules & documentation of approaches for editing & managing data through user interfaces.

[simontegg]

More on SOA: https://news.ycombinator.com/item?id=9676574

[simontegg]

Investigative Dashboard: (People and groups) https://www.google.com/ideas/products/investigative-dashboard/

Similar: http://www.theyrule.net/

[whyrusleeping]

ipfs weekly open development sprints: https://github.com/ipfs/pm, example sprint: ipfs/pm#11

ipfs dev here, whatsup? we're playing around with our open sprints a bit, so if youre interested in what we're doing (with regards to management) the issue here describes what we're doing: https://github.com/ipfs/community/issues/28

[simontegg]

Thanks @whyrusleeping we're just experimenting with our own processes and looking around at how other are doing it.

[simontegg]

New Annenberg survey results indicate that marketers are misrepresenting a large majority of Americans by claiming that Americans give out information about themselves as a tradeoff for benefits they receive. To the contrary, the survey reveals most Americans do not believe that ‘data for discounts’ is a square deal.

https://www.asc.upenn.edu/sites/default/files/TradeoffFallacy_1.pdf

[simontegg]

@ahdinosaur https://github.com/niftylettuce/gulp-aws-splash