OpenSym 2015, the 11th International Symposium on Open Collaboration
August 19-21, 2015 | San Francisco, California, U.S.A.
About the Conference
The 11th International Symposium on Open Collaboration (OpenSym 2015) is the premier conference on open collaboration research and practice, including free/libre/open source software, open data, IT-driven open innovation research, wikis and related open collaborative media, and Wikipedia and related Wikimedia projects.
OpenSym brings together the different strands of open collaboration research and practice, seeking to create synergies and inspire new collaborations between computer science and information systems researchers, social scientists, legal scholars, and everyone interested in understanding open collaboration and how it is changing the world.
OpenSym 2015 will be held in San Francisco, California, on August 19-21, 2015.
I’m in Hong Kong, attending FSE 2014. I had signed up for the Next-Generation Mining-Software-Repositories workshop at HKUST but missed it for (undisclosed) reasons. Apparently there were two main topics of dicussion:
- Calls by colleagues to make mining work “useful” rather than “just” interesting
- Calls by colleagues to build tools rather than “just” generate insight
Both issues are joined at the hip and an expression of a struggle over the definition of “what is good science” in software engineering. As someone who started out as a student of physics, I have an idea of science that views “interesting insights” as useful in their own right: You don’t need to build a tool that shows your insight improves the world. On the other end is the classic notion of engineering science, where there is no (publishable) research if you don’t improve the world in some tangible way.
Addison-Wesley asked the patterns community (or at least those who were there at the beginning) about their opinion on various issues. This is the second post of what should have been three (though I probably will only get to the first two).
Which Design Patterns Should Be Retired? (In Defense of Singleton)
For this very specific question, I expect everyone to say: Retire Singleton!
I beg to differ; for its time, Singleton was right. “Its time” mostly means single-threaded C++ code, as written by 3 of the 4 authors of the Design Patterns book. Today, many will argue that multi-threaded Java programs have made Singleton obsolete and even harmful. In my take at design patterns that would be wrong. Singleton should not perish, it should simply be adapted to its time. What ever thread-local information you may have, some it will be global to that thread. How is that not a thread-specific singleton? Or, take a group of application servers acting as a group: How is the group communication protocol not to provide a global id that makes the group identifiable and provide some global state attached to it? This may not be your granddaddy’s good ol’ singleton, but a singleton it may be nevertheless.
This is also where pattern descriptions will pass (or fail) the test of time: Does the original description of Singleton allow for these variations or not? If not, it may have been too narrow a description. I’d assume then that specific usage examples, tied to the programming languages and systems and technologies of its time, dominated the description and the abstracion process “out of examples, timeless patterns” did not yet conclude.
Beyond Singleton, some may want to retire Visitor, mostly because we find functional programming concepts being added to programming languages more and more, and multiple dispatch (which Visitor is about) comes for free. I say: Simply be precise about the scope. Visitor is (kind of) fine for Java but in a different context may not be needed as a design pattern because it has been cast as a language feature.
Design pattern should evolve and there is nothing wrong with it. John would approve.
A summary of all posts can be found on the InformIT site.
PS: Turned out, not many on the InformIT site were pointing to this issue. Looks like I was beating a dead horse!
Addison Wesley is going to celebrate the 20 year anniversary of the Design Patterns a.k.a. Gang-of-Four book. For this, they reached out to the community and asked for contributions. Here are the questions they asked, suggesting we ask (and answer) our own ones as well:
- How has Design Patterns affected you and your career?
- How has it changed how you think about software development?
- Do you have specific recollections of the book’s release?
- How do you use design patterns today?
- Which Patterns should be retired?
- Which new Patterns should be added?
I’ll provide my answers to questions 1-4 here and I’ll answer questions 5-6 in separate follow-on posts later.
The SE-2015-Konferenz ist die Konferenz der deutschen Software-Engineering-Gemeinde. Teil der SE 2015 ist der Software-Engineering-Ideen-Track, in dem neue und interessante Ideen vorgestellt werden können, die noch nicht als wissenschaftliche Ergebnisse validiert wurden. Wir versprechen uns von der Vorstellung dieser Ideen angeregte Diskussion und erhoffen resp. erwarten eine spätere Validierung. Aufgrund verschiedener Anfragen verlängern wir die Einreichungsfrist. Die neuen Deadlines lauten:
- Deadline Einreichung: 15.11.2014
- Author-Notification: 15.12.2014
- Camera Ready Deadline: 05.01.2015
Hier geht es zum ursprünglichen Call-for-Papers für den Software-Engineering-Ideen-Track der SE 2015.
The 11th International Conference on Open Source Systems (OSS 2015)
Co-located with the 2015 International Conference on Software Engineering (ICSE 2015)
Florence, Italy – 16-17 May 2015
Open frameworks: from service to cloud
Free and Open Source Software (FOSS) has had a disruptive effect on the commercial software industry and the ways that organizations and individuals create, distribute, acquire and use software and software-based services. In addition to the many standalone FOSS projects, FOSS is at the heart of modern network-based computing infrastructures and can be found in the vast majority of applications that run in these environments.
Springer Verlag by way of its incompetence to properly edit manuscripts has been a royal pain in my butt for a long-time. In the most egregious example, one of their editors changed the title of what was a crowning paper of many years of research work. He turned “open source” into “open course”, completely altering the focus of the paper as suggested by the title. I was not given a final proof-reading chance after that change and only found out about it when I saw the paper on their website. When I complained, Springer steadfastly refused to change the title to the correct original wording and only filed an Erratum that everybody thereafter of course ignored.