HN user
Sierra 1.0 and 1.1 actually took a similar approach - trying to create a DSL based on the standard layout managers.
However, I ultimately found that approach too limiting and went with custom layout managers for version 1.2.
I generally prefer links since otherwise the code and examples can easily get out of sync.
Have you looked into Flutter at all? I admit that I have not, but I know it supports web development in addition to mobile and desktop:
Added an example demonstrating how to add an action listener to a button:
https://github.com/HTTP-RPC/Sierra/blob/master/sierra-test/s...
I'm not sure it's exactly what you were looking for, but hopefully it is similar enough.
Sierra is actually inspired by Lima, a UIKit DSL I created in Swift before SwiftUI was announced:
Thanks for the feedback. I did consider using Kotlin but wanted to make sure it worked at least minimally in Java first.
Take a look at FlatLAF:
https://github.com/JFormDesigner/FlatLaf
They have done a great job bringing a modern appearance to the Swing components.
Agreed. I said as much in my response to this issue that was opened the other day:
Great question. You can do this with a cell consumer (i.e. the with() method). See OrientationTest for an example (e.g. leftToRightButton, rightToLeftButton):
https://github.com/HTTP-RPC/Sierra/blob/master/sierra-test/s...
I should probably add a better example.
UIStackView is a step in the right direction, but it doesn't go far enough. It's still not truly declarative; it requires you to think in terms of content priorities; and it doesn't support z-ordering.
Actually, Lima is partly a move away from using XML:
For one, you can't create a hierarchy of UIStackViews and their contents declaratively. But UIStackView also forces you to think in terms of content hugging and compression resistance priorities, which (to me) isn't as natural as widths, heights, or weights.
I understand the GraphQL pitch - I just don't buy it. From my experience, you don't generally need that level of flexibility. Most callers probably want the full set of data returned by your API. Those that don't can easily ignore it or filter it out client-side. So GraphQL is basically a big, unnecessary hammer.
Demonstration of how to create a GraphQL-like API using REST.
Hi all. I'm the author of this project on GitHub. It seems like it might be a good foundation for building microservices in Java. However, I'm not a microservices expert, so I was wondering what others with more experience in this space think. Thanks!
I agree that 1 - 2 hours of homework may be excessive. However, 10, 20, or even 30 minutes seems reasonable to me, assuming that it reinforces what is being taught in school.
And yet, most of the population won't end up making a living from their sporting accomplishments. However, they will get a job based on what they learned (or didn't learn) in school.
That sounds cool. WebRPC isn't meant to be an "everything to everyone" solution. It's main advantage is simplicity and low overhead. It allows you to quickly and easily build a service tier that is consumable by multiple clients. But if your requirements scale beyond what WebRPC provides, Thrift sounds like a great option.
If you are implementing a REST service, then I agree with you 100%. WebRPC is simply a different interpretation. In WebRPC, GET means "get the result of executing this method". POST basically means the same thing, but the arguments are passed in the message body (just like an HTML form).
The client libraries all use POST internally - GET is primarily useful for testing and debugging (so you can easily execute a method in the browser).
Not sure. The client libraries don't work with sockets directly. The Java client uses HTTPURLConnection, the Objective-C/Swift client uses NSURLSession, and the JavaScript client uses XMLHttpRequest. You'd have to check the documentation for each of those to see what they might be doing under the hood, or what options you might have for configuring them. Same goes for the server, which just sits on top of a servlet container. You'd have to see the container docs to see what your options are.
WebRPC is a lot lighter than XML-RPC (or JSON-RPC). It's really just a thin layer on top of HTTP. Arguments are passed in the query string (or as form parameters, if POSTing), and the response value is returned directly as JSON. There's no body or envelope to parse. This makes WebRPC services really easy to consume by any client that supports HTTP and JSON (which is pretty much most platforms). WebRPC services are also really easy to test, since you can execute a method and get the results back simply by typing a URL in your browser.
I haven't used Thrift myself, but I just took a quick look at the docs. My initial reaction is that Thrift seems to be a bit heavier. WebRPC doesn't require any intermediate interface definitions and doesn't create language-specific client proxies. Method invocations are all dynamic (although you could easily wrap the invocation API in a statically typed adapter if you wanted to).
WebRPC isn't meant to be a replacement for REST - just an alternative. Sometimes it's simply more convenient to think in terms of "methods" than "resources".
Some additional information and examples:
A Quick Introduction to WebRPC
https://gkbrown.wordpress.com/2015/08/25/introducing-webrpc/
A Practical Example Using MarkupKit and WebRPC
https://gkbrown.wordpress.com/2015/09/08/a-practical-example...
A Practical Example Using WebRPC and Android
https://gkbrown.wordpress.com/2015/10/06/a-practical-example...
I've been antenna-only for 6+ years now. My first antenna cost $60 and was OK. After a couple of years, I replaced it with a $100 version that is much better. I rarely ever have any issues with it.
When I got my TiVo a few years ago, you could buy a lifetime subscription. I think it was about $300, which seemed pretty reasonable. I've had the unit for almost 4 years so I've definitely broken even on it.
They still seem to offer a lifetime plan, but now it costs $600. That's a bit harder to justify.
It uses autolayout. The details of constraint management are abstracted by layout views such as LMRowView and LMColumnView. You can also use the new UIStackView class Apple added in iOS 9. See this article for more information:
https://gkbrown.wordpress.com/2015/09/29/using-uistackview-w...
XAML was definitely one of the inspirations for MarkupKit. It was also inspired in part by MXML (Apache Flex), FXML (JavaFX), and to some extent HTML. It's also conceptually similar to the markup language used to build Android applications, though I don't have much experience with that.
Some additional information and examples:
Implementing Radio Button-Like Behavior in iOS Applications
https://gkbrown.wordpress.com/2015/08/10/using-lmtableview-t...
Creating Custom Table View Cells in Markup
https://gkbrown.wordpress.com/2015/08/19/creating-custom-tab...
Using UIStackView with MarkupKit
https://gkbrown.wordpress.com/2015/09/29/using-uistackview-w...
MarkupKit Examples
https://gkbrown.wordpress.com/2015/08/14/markupkit-examples/
A Practical Example Using MarkupKit and WebRPC
https://gkbrown.wordpress.com/2015/09/08/a-practical-example...
Same here (although I toss them in the recycling bin).
Things may have changed recently, but online YP searches have typically been just as frustrating. Most of the time, the top search results are paid promotions nowhere near me and sometimes not even relevant to my search.