tekacs

57 ms·

631.
by tekacs 12y ago
The article seems to describe a system which has funnel-shaped dataflow (narrow inlet, spread to services), which is also a side-effect of the 'API Gateway' approach you mention. Three useful definitions[1] for microservices are:
632.
by tekacs 12y ago
One option is a framework[1] which tries to start dependent services locally. A stopgap solution is to use something like an Actor[2] model, which schedules actors on an ActorSystem and to clone the context/scheduler/system for ea
633.
by tekacs 12y ago
It absolutely is. It's for exactly these reasons why only highly organised and qualified teams tend to have substantial microservice deployments today. It's also why I think[1] we need to start building a framework[2] to provide s
634.
by tekacs 12y ago
> unless you understand trees as a data structure Well unless you understand DAGs, more like? Which is somewhat more unhelpful. :P (given that merge commits have multiple parents)
635.
by tekacs 12y ago
I beg to disagree. I just gave a talk[1] about exactly how we[2] went back and took time to learn lessons from designs like CORBA (we're building another microservices framework). Not least I talk about how it's important to build
636.
by tekacs 12y ago
Hey, sorry - when I came to Scala I'd seen enough other languages that I read the language spec[1] and learned most of it in a day. Since I never spent time onboarding myself, I'm not sure I can be any help. :/ The docs websi
637.
by tekacs 12y ago
> drawbacks that complicated type systems have: hellish compiler messages and long compile times Scala has incredibly nice compiler messages and you can see Rust for an example of a language with complex types and short compile times. Th
638.
by tekacs 12y ago
Ask and I shall deliver. Fixed. :P I'll upload our build setup right about when I write a blog response to the OP's post. :) The chief point to note is that the components need to render as you want non-JS viewers to see them when
639.
by tekacs 12y ago
Who don't necessarily need it, because they don't live in the US...
640.
by tekacs 12y ago
The weakness of the type system becomes a problem pretty quickly - simply having a different implementation of an adaptor, be it per language, transport or even simply type of node makes for an endlessly leaking abstraction. That's wha
641.
by tekacs 12y ago
Hm, that's interesting. I went to great lengths to ensure it rendered without JS (since it's all React)! :P I'll look into it. Thanks. :)
642.
by tekacs 12y ago
I didn't mention in it my sibling post here, but we started writing the core of wym (our microservices framework) in Go, then Node.js and finally settled on Scala for exactly the reasons you outline. Writing in those other languages wa
643.
by tekacs 12y ago
Addressing each of your points in turn: - What's the difference from a spec? There used to be a FAQ on our site emphasising that at its core _wym_ is a spec. Our reference implementation, itself made up of multiple pieces (wymd, wymsy,
644.
by tekacs 12y ago
This is well written. I gave a talk at the (unaffiliated) Hacker News London Meetup on composing a microservice architecture and why I think a framework to bind today's disparate components needs to exist: http://vimeo.com&#
645.
by tekacs 12y ago
This is brilliant! Another vote for SBT!
646.
by tekacs 12y ago
Someone with spare time should be able to write a quick CI script to build a blog with any static site generator. The structure is perfect for that, of course. :)
647.
by tekacs 12y ago
The first time someone pointed this shortcut out to me I thought they were pulling my leg. I never expected GitHub to have shortcuts, somehow. Glad to help and again, nice work. :)
648.
by tekacs 12y ago
It might be worth turning your GitHub links in the article into permalinks (hit 'y' in the GH interface once you've targeted the file and line) so they don't fall out of date. Nice work!
649.
by tekacs 12y ago
> Anyone working in this space 20 years ago couldn’t possibly have known of their problems so every problem deserves a new solution. It's worth noting that sometimes the reason for developing a new solution is to be free of the bagg
650.
by tekacs 12y ago
... unfortunately the state of Linux on laptops makes the all-too-common case of _repurposing_ a laptop incredibly painful. :/ ... unless you think ahead and only buy (and recommend) Thinkpads.
651.
Microcontrollers Not Allowed – Trolling a college instructor(ultrakeet.com.au)
447 points by tekacs 12y ago|100 comments
652.
by tekacs 12y ago
> Personally, I'd like to see a concept map of essential computer science topics combined with some of the top papers and books that cover each. It could be implemented as a curated collapsable directed graph. I've tried buildi
653.
by tekacs 12y ago
For some textual context: http://xiph.org/daala/
654.
by tekacs 12y ago
Tasker, for one: http://tasker.dinglisch.net/ You can make apps of tasks and so on, too.
655.
New tech uses ultrasound to create haptics you can 'see' and touch(engadget.com)
2 points by tekacs 12y ago|0 comments
656.
by tekacs 12y ago
Several of the services here are pretty interesting (Slack, DigitalOcean, Algolia (they run HN's search)): http://www.producthunt.com/e/black-friday-startup-toolkit
657.
by tekacs 12y ago
It depends on the case, but an easy way to emit progress indicators in our system is to make the long-running service a generator. It looks like this: g = wym('/email') #=> Generator(id=<...>) g.on('va
658.
by tekacs 12y ago
Part of the notion is that any piece of code _can_ be a microservice. The way our framework does it, very nearly any function can trivially be turned into a microservice. It becomes a _service_ once it gains communications and a global name
659.
by tekacs 12y ago
In light of your further questions, I feel like I should post. We're working on a microservice framework which: - does the routing to and from the actual microservices - provides a structured enough interface (through our sma
660.
by tekacs 12y ago
Recent discussion: https://news.ycombinator.com/item?id=8218785

More ›