Dave Orme muses about agile and functional programming.
My current work emphasizes SOA applications using Scala, Kubernetes, and AWS with a React-based SPA front-end. I'm also interested in progressive web applications and developer tools.
Donate Bitcoin:
1Ecnr9vtkC8b9FvmQjQaJ9ZsHB127UzVD6
Keywords:
Kubernetes, Docker, Streaming Data, Spark, Scala, Clojure, OSGi, Karaf, GCP, AWS, SQL
Disclaimer:
Everything I say here is my own opinion and not necessarily that of my employer.
Here's a collection of Monad-related tutorials for Java and/or Scala that have been useful to me:
~~LINKBACK~~ ~~DISCUSSION~~
Last night I spoke about monads to the Chicago Scala group. It was a good time, and hopefully profitable to all.
One of the most fun parts was a thought exercise we did together at the end: Finishing implementing monadic behavior over Java's Iterable<T>…
Anyway, I didn't present using a slide deck this time, but put all my notes into a mind map using XMind, collapsed all the nodes below the 1st level, and used the drill up/down feature to show the content and come back to the overview. Notes attached to nodes contain code snippets and examples.
The approach worked nicely, but has the side effect that one can't easily publish the results on the web.
So, without further ado, here's an HTML export of my notes from XMind. Hopefully I'll have a chance to rewrite the presentation as an article, but until then… :)
http://www.coconut-palm-software.com/monads/html/Monads.html
~~LINKBACK~~ ~~DISCUSSION~~
I've been busy writing Eclipse RCP software for a major investment bank and away from blogging for quite awhile, hopefully that will change again soon. :) There are lots of interesting things to write about. :D
A brief additional note: I've updated the blog software. The main issue I'm noticing is that a few of the historical articles are out of order. I've also turned off user registrations and comments for new articles for now although all of the historical comments still show.
~~DISCUSSION:closed~~
In my previous entry, I referred to Kai's blog where various community members wished for a simpler data binding API and asked for comments.
This blog is intended to collect the various proposals I've seen for simplifying data binding into one place so we can discuss their relative merits.
First, I'll state my personal biases.
Second, what are the various ways to raise the level of abstraction?
The bindable widgets themselves have the intelligence needed to bind them.
I dislike this approach for several reasons.
This is the approach of things like Beans Binding, as well as several well-known scripting languages like Perl and Ruby.
Folks would like to write something like:
String someOutput = "Hello, my name is ${person.firstName} ${person.lastName}";
Or (from bug 195222):
BeanObservables.observeValue(person,"parents[@mother=true]/person/name");
My personal thought here is that:
Basically, I like it but it sounds like a lot of work.
Using the Builder pattern, one could easily imagine something like:
IValueProperty objectAddressStreet = BeanPropertyBuilder.value("address").value("street").build();
More thoughts along these lines are in bug 195222 and bug 194734
Someone on the E4 developer list (sorry, I'm too lazy to look up who said this) complained that data binding's problem is that it conflates data flow with the user's work flow.
In other words, it directly represents data flow in the observables and the binding:
dbc.bind(SWTObservables.observeText(txtFirstName, SWT.FocusOut), BeansObservables.observeProperty(person, "firstName"), null, null);
But if you need to alter the user's work flow, for example through validation, then this validation code becomes a cross-cutting concern across all of your bindings.
However, unless one uses something like AspectJ, this seems like essential complexity to me.
Somebody please prove me wrong.
Please comment.
20081226: Edit: Fixed link to Kai's blog entry
~~LINKBACK~~ ~~DISCUSSION:closed~~
Have you ever wanted 100% transparent persistence for your memory-based EMF models?
As-in, after issuing one line to connect a Resource to a directory in your file system, you don't have to think about persistence any longer; you just manipulate your model using regular EMF and Java code. And all changes are automatically persisted to disk.
If so, maybe you would like something like the following:
// Given the following helper method: private Resource makePersistentSystem(String tempDirPath) { Resource newSystem = new XMIResourceImpl(); EmfPersister persister = new EmfPersister(newSystem, tempDirPath, -1); Resource persistentSystem = persister.getPersistentSystemRoot(); // Get the persistent decorator return persistentSystem; } // We can write: String tempDirPath = tempDir().getAbsolutePath(); // Create a Resource and make it persistent Resource persistentSystem = makePersistentSystem(tempDirPath); // Add a Person to the persistent resource Person person = factory.createPerson(); person.setFirstName("Dave"); persistentSystem.getContents().add(person); // Create a second (empty) Resource Resource secondSystem = new XMIResourceImpl(); // Attach it to the persistent system's directory, which will restore the // first system's contents into the second one new EmfPersister(secondSystem, tempDirPath, -1); // Now the second system should have a *copy* of the Person above assertEquals(1, secondSystem.getContents().size()); Person restoredPerson = (Person) secondSystem.getContents().get(0); assertTrue("Structurally equal", EcoreUtil.equals(person, restoredPerson)); assertFalse("Not the same object", restoredPerson.equals(person));
What's happening here is that whenever an object inside the Resource is mutated, Prevayler transparently notes this fact in a transaction journal in the specified directory. You don't have to do anything to make it happen.
The current implementation puts a decorator around every EMF object that intercepts method calls and if they mutate state, runs them through Prevayler.
So far there are only two catches.
1) When you create a new object, after adding it to a PreMF-managed object graph, you have to remember to either manually call the API that makes the object reference itself persistent, or just get it back out of the object graph (which will give you a persistent version).
2) #equals behaves slightly differently with persistent and non-persistent objects. If you ask a persistent object if it is equal to a non-persistent object, it will do the right thing. But a non-persistent object won't know how to compare itself with a persistent object. This only matters if you forget to make a new object reference persistent after adding it to the persistent object graph (as described in #1).
The current experimental implementation just makes the contents of XMLResource#getContents() persistent. Work is underway to make the rest of the EMF API persistent the same way.
Does this sound interesting/exciting?
I'm still an EMF newbie. Details of the approach/design are in the README.md on GitHub:
https://github.com/pieceoftheloaf/emf-prevayler
I'd love to hear what people think of this and/or if there's a better way to accomplish the same thing.
~~LINKBACK~~ ~~DISCUSSION:closed~~
On his blog, Ian Skerrett invites people to comment on when/how they joined Eclipse. As I responded, I found I was sort of writing an Agile Retrospective. Since those thoughts felt like they might be valuable on a larger scale, I am repeating them here.
I became a member of the Eclipse Consortium during the year that we were creating the Foundation. I will never forget the Consortium’s last meeting held at the American Airlines conference facility in Dallas where the mood was festive because we had done what we set out to do–we had created the Eclipse Foundation and we were officially handing the keys to Eclipse over to them.
My official job was to represent a small software development company that made a good living adding value to IBM’s iSeries tooling built on top of Eclipse. Unofficially, I became a voice for many small companies and especially for the community of open source developers.
This led to interesting opportunities: One was the opportunity to negotiate on a conference call with the big company lawyers about how the patent retaliation clause in the EPL would work out in practice for software developers. Many software developers have a very negative view of corporate lawyers, but these were clearly on our side, had a clue, and were a joy to work with. On the other hand, I had a very engaging conversation with Richard Stallman about the relationship between Free Software and Open Source (and Eclipse in particular) when the Free Software community urged us to make the EPL compatible with the GPL.
(Over the years, Eclipse has truly attracted some of the best of the best minds I have ever worked with.)
In the end, the EPL and GPL have managed to coexist inside Linux distributions, and I personally appreciate both the passion of the hard-core Linux community and the powerful pragmatism the Eclipse community had when it created a truly symbiotic relationship between big corporations and open-source.
In my own view, it is this powerful pragmatism combined with open-source symbiotic coopetition that has made, and continues to make the Eclipse community great.
Looking forward, I believe that the biggest challenge Eclipse (and, indeed all of Java) faces is that we are hitting the complexity wall of what can be done with the Java language. OSGi goes a long way toward helping on one front. EMF helps a lot on another.
The challenge I would put before the community today is to embrace and incorporate the emerging agile/functional languages like Scala, Groovy, JRuby fully into the Eclipse, Modeling, and OSGi ecosystems.
This will continue to ensure that the small developer with the New, Cool idea has a powerful enough lever that we will continue to see awesome ideas like Mylyn and many of the EMF ideas sprout, take hold, and grow up within the Eclipse ecosystem.
~~LINKBACK~~ ~~DISCUSSION:closed~~
As promised, I've updated the P2 updater/installer example that Patrick Paulin and I presented at EclipseCon to demonstrate how to use this code in a production manner.
Here's the original EclipseCon session announcement. And the original EclipseCon presentation and code examples we used back at the conference.
Enjoy!
~~LINKBACK~~ ~~DISCUSSION:closed~~
Have you ever wondered why it seems so hard to come up the OSGi or RCP learning curve? Or, if you're already an OSGi expert, why beginners seem to have so much trouble “getting it”?
I believe one reason is that there is an impedance mismatch between the way OSGi applications are built and the way the Eclipse IDE works. More importantly, I believe that understanding this impedance mismatch illuminates a very fundamental architectural pattern in OSGi development that I call the OSGi Building Block pattern.
In this blog article, I will discuss the OSGi Building Block pattern in the abstract.
Next week at EclipseCon, Patrick Paulin and I will deliver real code showing how to leverage this pattern to make Eclipse RCP and server-side OSGi application development much easier (Architecture Patterns and Code Templates for Enterprise RCP Applications).
Consider this thought:
Eclipse works in terms of projects and dependencies. But no single project can fully define a production-quality OSGi application.
Why?
Let's use Eclipse RCP as an example:
An RCP developer might first use the “RCP Application with a View” wizard to create her initial RCP application. This wizard generates a single project defining a single OSGi Bundle.
Then the average beginner clicks the “Run” button to launch the platform and to see the wizard's result.
But in order to deploy the application, an RCP developer must create at least the following extra artifact(s):
and normally for an enterprise-class project:
And there is nowhere that I am aware that documents all of these steps in one place. So a beginning RCP developer may flounder for months before he realizes what the minimal ingredients are in a production-ready Eclipse RCP application.
For a Feature-based RCP product, the minimal building-block for a production-quality application can be represented by the following quad:
(Bundle+, Feature+, Product, Releng)
[The trailing plus sign signifies “one or more”, just like in a grammar.]
In other words, for production purposes, the *minimal* RCP application is:
But Eclipse provides no wizards to create all of these things at once. Eclipse provides no refactorings to keep all of these things in sync as they change over time.
The Eclipse RCP wizard and the Eclipse IDE want us to think in projects. But OSGi wants us to think in terms of deployable bundles. Eclipse requires the OSGi (RCP, server-side) developer to keep this entire model in his head, and to manage it manually.
(I think I mentioned that we will deliver simple code illustrating all of this next week? 
)
Wait! There's more!
The same principle applies for server-side OSGi, just with different names for the parts! For example, Virgo has the following minimal building-block:
(Bundle+, Plan+, ContainerConfig, Releng)
(Okay, I know you can deploy bundles to a WAR, but my understanding is that Plan files are the “new and approved” way to work with Virgo.)
And an OSGi bundle, deployed via P2 is the following minimal set of things:
(Bundle+, Feature+, P2RepoProject, Releng)
Viewing OSGi this way has helped me think about RCP applications much more clearly, because the number of distinct concepts I have to keep track of suddenly just went to 4.
It has also helped me understand how to design my builds in a modular way, because as Nick Boldt blogged, a build's target platform can be composed of multiple P2 repositories, which can be the result of prior builds. In other words, my build can consume its own output.
I call this OSGi quad the “OSGi Building Block” pattern because it comes up frequently in one form or another in nearly all flavors of OSGi software development. The general form can be described as:
(Bundle+, Packaging+, Deployment, Release engineering)
I believe there are two powerful ramifications to this:
Following this second point, I would like to issue the following challenge and invitation to the OSGi community:
To facilitate these discussions, I would like to invite all of the OSGi stakeholders to a BoF session this coming week at EclipseCon.
I think that OSGi's future is bright, and I think that by driving concrete plans to improve developers' lives using the OSGi Building Block pattern, we can help.
(And one final plug for Patrick and my session next week:)
If you're wondering why and how this makes OSGi development simple, come to our tutorial next week at EclipseCon: Architecture Patterns and Code Templates for Enterprise RCP Applications. Next week Patrick Paulin and I will make all of these abstract ideas concrete with real code you can take with you and use as the basis for your next project.
~~LINKBACK~~ ~~DISCUSSION:closed~~
