I confess that I haven't study core.async yet. I.e. I don't know the clojure way to work asynchronously, but I know that is mostly using channels. I work mainly in clojurescript and I'm going to start writing a service worker.
I found this library to write promises as channels, but it feels there is not a lot of work to do without using the library or not.
So, should I use channels over promises in any situation?
Is there a simple convertion from promises to core.async using channels?
If you look over the original rational for core.async, it becomes clearer when it has advantages over using another thread such as with future. ClojureScript was one of the big drivers, since it is single-threaded and there is no other options.
Some resources:
https://clojure.org/news/2013/06/28/clojure-clore-async-channels
https://github.com/clojure/core.async/blob/master/examples/walkthrough.clj
https://cognitect.com/videos.html (2 on CLJS core.async)
https://github.com/cognitect/async-webinar
https://rigsomelight.com/drafts/clojurescript-core-async-todos.html
https://medium.com/#loganpowell/cljs-core-async-101-f6522faf536d
Has anyone tried implementing a new transport for Rebus? How much work is involved? E.g. number of interfaces that needs to be implemented? Assuming a sensible transport mechanism is used such as Greg Youngs event store..
Thank you.
As the aptly named #user1121956 says, it's a matter of implementing IDuplexTransport, which is just bringing ISendMessages and IReceiveMessages together.
As you can see, the two interfaces boil down to two methods, so when I say that it's a lot of work to implement a new transport, it's because it's not trivial to implement those methods.
It doesn't mean that it's not possible, it's just that it's a place where you would need to be very careful to get things right - otherwise, messages might be dropped or other bad things might happen, and that would not be cool :)
With that said - if you feel like you're up to it ;) - I suggest you check out the Rebus source code and look into the contract tests for the transports - this is where a bunch of common scenarios get run against all the officially supported transports. A good starting point would be to extend the tests with a GregsEventStoreTransportFactory.
I will be happy to help you out with guidance along the way if you run into trouble!
I've been programming in Delphi with Midas/DataSnap for quite long time and quite happy with it. Moving to .NET I'm more than happy with the ADO.NET DataSet. For CRUD application, I'm highly uncomfortable with any kind of ORM. Generic data-structure with automatic diff/delta handling get my job done better for me, an average database application developer.
Tried to study Java years ago, and could not find similar idea implemented. The closest I could find is SDO (Service Data Object). I thought it should be widely adopted when I saw it, but I'm wrong. Even the spec is rather old now, I still hardly find many people discuss on it or use it extensively. Assuming from information I can find on the internet, SDO usage is highly passive.
Wondering if it's dying ? Any experience in SDO you want to share ? Manual DTO coding is always better ?
Ok. I see. The answer is "no"
;)
Same for me when trying SDO first time. Old specs, passive feedback... Definitely NO.
I wouldn't recommend using SDO unless it's imposed on you by some other part of the project.
WebSphere process server uses SDO. It's not really a bad API once you learn it. But the spec and the documentation are vague. It doesn't spell out what happens if you ask for a field that doesn't exist, or whether it does type conversions while getting or setting fields, to name two gripes.
I don't think the API defines how to define new types, so that part will be implementation-specific. Type definitions are based on XSD, so you'll be working with those and all of the associated standards.
As others have implied, the API isn't widely used. This means it'll be hard to find people experienced with it, or help using it.
I've been starting to figure out how to use noir and I would now like to use http basic authentication.
I've stumbled upon https://github.com/adeel/ring-http-basic-auth . Though, the given examples seem to apply to compojure and not to noir.
I wonder if noir's abstraction level is too high to allow different auth for diferent pages?!
I also know that this could be the way do go: http://webnoir.org/tutorials/others , though, I am not yet confortable enough with the whole clojure ecosystem in order to be able to see how to fit these ring handlers as http authentication for specific routes.
Is there anyone who can give me a hint about how should I think about this problem?
Thank you,
Check out Friend: https://github.com/cemerick/friend
It is a authorization/authentication library that works as ring middleware. Very easy to get up and going with.
Somebody that I work with and respect once remarked to me that there shouldn't be any need for the use of reflection in application code and that it should only be used in frameworks. He was speaking from a J2EE background and my professional experience of that platform does generally bear that out; although I have written reflective application code using Java once or twice.
My experience of Ruby on Rails is radically different, because Ruby pretty much encourages you to write dynamic code. Much of what Rails gives you simply wouldn't be possible without reflection and metaprogramming and many of the same techniques are equally as applicable and useful to your application code.
Do you agree with the viewpoint that reflection is for frameworks only? I'd be interested to hear your opinions and experiences.
There's the old joke that any sufficiently sophisticated system written in a statically-typed language contains an incomplete, inferior implementation of Lisp.
Since your requirements tend to become more complicated as a project evolves, you often eventually find that the common idioms in statically-typed object systems eventually hit a wall. Sometimes reaching for reflection is the best solution.
I'm happy in dynamically-typed languages like Ruby, and statically-typed languages like C#, but the implicit reflection in Ruby often makes for simpler, easier-to-read code. (Depending on the metaprogramming magic required, sometimes harder to write).
In C#, I've found problems that couldn't be solved without reflection, because of information I didn't have until runtime. One example: When trying to manipulate some third-party code that generated proxies to Silverlight objects running in another process, I had to use reflection to invoke a specific strongly-typed "Generic" version of a method, because the marshalling required the caller to make an assumption about the type of the object in the other process was in order to extract the data we needed from it, and C# doesn't allow the "type" of the generic method invocation to be specified at run time (except with reflection techniques). I guess you could argue our tool was kind of a framework, but I could easily imagine a case in an ordinary application facing a similar problem.
Reflection makes DRY a lot easier. It's certainly possible to write DRY code without reflection, but it's often much more verbose.
If some piece of information is encoded in my program in one way, why wouldn't I use reflection to get at it, if that's the easiest way?
It sounds like he's talking about Java specifically. And in that case, he's just citing a special case of this: in Java, reflection is so wonky it's almost never the easiest way to do something. :-) In other languages like Ruby, as you've seen, it often is.
Reflection is definitely heavily used in frameworks, but when used correctly can help simplify code in applications.
One example I've seen before is using a JDK Proxy of a large interface (20+ methods) to wrap (i.e. delegate to) a specific implementation. Only a couple of methods were overridden using a InvocationHandler, the rest of the methods were invoked via reflection.
Reflection can be useful, but it is slower that doing a regular method call. See this reflection comparison.
Reflection in Java is generally not necessary. It may be the quickest way to solve a certain problem, but I would rather work out the underlying problem that causes you to think it's necessary in app code. I believe this because it frequently pushes errors from compile time to run time, which is always a Bad Thing for large enough software that testing is non-trivial.
I disagree, my application uses reflection to dynamically create providers. I might also use reflection to control logic flow, if the logic is simple and doesn't warrant a more complicated pattern.
In C# I use reflection to grab attributes off Enumeration which help me determine how to display an enumeration to an end user.
I disagree, reflection is very useful in application code and I find myself using it quite often. Most recently, I had to use reflection to load an assembly (in order to investigate its public types) from just the path of the assembly.
Several opinions on this subject are expressed here...
What is reflection and why is it useful?
Use reflection when there is no other way! This is a matter of performance!
If you have looked into .NET performance pitfalls before, it might not surprise you how slow the normal reflection is: a simple test with repeated access to an int property proved to be ~1000 times slower using reflection compared to the direct access to the property (comparing the average of the median 80% of the measured times).
See this: .NET reflection - performance
MSDN has a pretty nice article about When Should You Use Reflection?
If your problem is best solved by using reflection, you should use it.
(Note that the definition of 'best' is something learnt by experience :)
The definition of framework vs. application isn't all that black & white either. Sometimes your app needs a bit of framework to do its job well.
I think the observation that there shouldn't be any need for the use of reflection in application code and that it should only be used in frameworks is more or less true.
On the spectrum of how coupled some piece of code are, code joined by reflection are as loosely coupled as they come.
As such, the code which is doing it's job via reflection can quite happily fulfil it's role in life knowing not-a-thing about the code which is using it.