Older blog entries for mindcrime (starting at number 51)

25 Feb 2011 (updated 20 Aug 2012 at 02:43 UTC) »

ScrewPile Update 02-24-2011

Activity around Fogcutter has been frantic since our last update. Neddick release TPR2 was finally released and that code has been pushed to the demo server. TPR2 features UI improvements, bugfixes related to the tagging feature, the introduction of scheduled jobs, and the addition of scheduled jobs for rebuilding the entry cache and populating channels from RSS feeds


On the Quoddy front, the user-profile support has been radically improved and the UI for editing profiles has been cleaned up considerably. A preliminary preview release should be out soon. The main feature that we want to get in for a TPR1 release of Quoddy is basic "activity stream" support (think the "Wall" feature on Facebook.)

We've also started digging into the Mahout clustering code, and are starting to look into implementing some of the neat stuff that you can do with Machine Learning and Text Mining. An "auto tagging" feature and a better "related links" feature for Neddick are on the drawing board.

See the roadmap page for more on what's coming in the short-term.

Syndicated 2011-02-25 03:33:00 from ScrewPile Dev

14 Jan 2011 (updated 20 Aug 2012 at 02:44 UTC) »

What's New With ScrewPile?


Since the last post, we've made a ton of commits to Quoddy - our Open Source Enterprise Social Networking platform (which is receiving most of the attention right now.) The most recent batch of changes have been focused on LDAP integration and User Profile editing.


Specifically, we've made all use of LDAP optional (the first pass at adding LDAP support actually assumed LDAP would always be present) by finishing up the "Local Accounts" support. We also added LDAP User Import, and we now fully support a mixed authentication mode where both "Local Account" users and (optionally) external LDAP users may log in. We've also started adding some (very) primitive support for editing User Profiles, and we added the very first UNIT TEST! Yes, the intent is to have a comprehensive test suite, but we'd been neglecting that stuff while doing a lot of exploratory programming earlier.


Yeah, it's considered back form to write the code first and retrofit the tests, but in this case we think it's going to be OK. There isn't *that* much code to test.


On that note, after cloning the repo, if you want to see the current test coverage metrics, just

[user@somehost quoddy]$ grails install-plugin code-coverage
and then
[user@somehost quoddy]$ grails test-app unit: -coverage
to generate the coverage report.


Other changes: rev'd the Grails version to 1.3.6, and switched to using Groovy 1.7.6 for development.


And that about covers it. Check the TODO or the roadmap for more on what's coming down the pike.

Syndicated 2011-01-14 03:04:00 from ScrewPile Dev

OpenSocial working (sort of)!

The first primitive bit of OpenSocial support is now wired into Quoddy. Don't believe me? Fine, here's the first screenshot:




Syndicated 2010-12-23 08:48:00 from ScrewPile Dev

ScrewPile Update 12-22-2010

Since our last update, a lot of work has gone into Quoddy. The latest code includes support for using LDAP for user account information, has support for creating and listing "friends" and "followers" and has some primitive activity stream stuff in place... and to top it all off, work has begun on adding OpenSocial support using Apache Shindig. The OpenSocial stuff isn't finished by any stretch of the imagination, but I hope to be able to deploy and render at least a "hello, world" Gadget sometime tonight / tomorrow morning.


To take a look at the latest changes, check the Quoddy repo on GitHub.

Syndicated 2010-12-23 01:32:00 from ScrewPile Dev

ScrewPile Update 12-01-2010

Not a lot to report since last time... I (Phil) have been in more of a "research" mode than a "coding" mode lately, trying to get more up to speed on some of the theoretical stuff vis-a-vis Information Retrieval, Network Science and Evolutionary Computation. But expect some progress on Neddick - at least - in the near future.

In the mean-time, take a gander at some of the cool stuff that's going on over at the ASF. A lot of new projects are showing up there, that may be useful for the ScrewPile projects. In particular, there's a lot fo Semantic Web related activity going on, as well as some Content Management stuff. Check out Stanbol, Chemistry, Clerezza, and note that Jena is becoming an Apache project.

Syndicated 2010-12-01 05:01:00 from ScrewPile Dev

26 Jul 2010 (updated 20 Aug 2012 at 02:46 UTC) »

ScrewPile update for 07-25-2010

So, what's new since last time? Well, not everything one might have hoped for, but a few Neddick bugs have been fixed at least, and progress continues on. We still hope to have Neddick TPR2 out by the end of August, and maybe a solid start on Heceta.

Specifically regarding Neddick, since last time, the bugs that have been resolved are:

Bug #12 - Make "tag" box work when pressing ENTER] - FIXED

Bug #8 - Get arrows for up/down vote links - FIXED

Bug #25 - Create scheduler mechanism for asynchronous updates - FIXED

Bug #35 - Need scheduled job to rebuild entrycache on some periodic basis - FIXED

The scheduled task stuff turned out to be pretty simple, thanks for the excellent Quartz Plugin for Grails. Now the EntryCache gets refreshed once a minute. Additionally, even though it wasn't in the bug list as a discrete bug, a problem with recalculating the score of an entry - after an upvote was removed - has been fixed.

As to what's coming next... mainly work on the next Neddick TPR, so see the Roadmap for details. The bugs on the roadmap page are now sorted (more or less) by the order in which we intend to attack them, so it should be pretty easy to tell where things are going.

And that's a wrap, for this week.

Syndicated 2010-07-26 03:36:00 from ScrewPile Dev

What's new with ScrewPile?

Since the last post, all sorts of stuff has gone on! Things are progressing nicely, especially with Neddick. Since last time we've registered each of the ScrewPile subprojects with sited dedicated to F/OSS, such as Ohloh.net, Advogato.org, and Freshmeat.net. Source code has been pushed to GitHub and the Google Code SVN repository. We've gotten Bugzilla and IceScrum installed and configured, and we have a live Neddick demo site up and running. Additionally, documentation has been written on our development process, and some roadmap documentation has been put together. We've also put together a site at Fogbeam.org dedicated to Fogbeam's open source activities.

Not a bad week's work, eh?

So, for your browsing convenience, here are links to all the new hotness:

Neddick demo site

http://www.fogbeam.org/
http://dev.fogbeam.org/
Bugzilla
IceScrum

Development Process Doc
Neddick Roadmap


Neddick on GitHub
Quoddy on GitHub
Heceta on GitHub

Neddick on Freshmeat
Quoddy on Freshmeat
Heceta on Freshmeat

Neddick on Advogato.org
Quoddy on Advogato.org
Heceta on Advogato.org

Neddick on Ohloh.net
Quoddy on Ohloh.net
Heceta on Ohloh.net

I think that's about it. Whew...

Anyway, what's coming next? Well, all of the stuff from the Neddick roadmap, and we also need to get a proper Ant build setup, some tests written, and Hudson installed and configured to do continuous integration and automated testing.

The Neddick screencast should also be forthcoming shortly, which should be fairly enlightening.

And that's about it. Any questions, just leave a comment here, or join the ScrewPile-dev or ScrewPile-discuss Google Group and post there.

Syndicated 2010-07-14 01:29:00 from ScrewPile Dev

11 Jul 2010 (updated 20 Aug 2012 at 02:49 UTC) »

Welcome to ScrewPile

(edit: everything below is true, with the addendum that "ScrewPile" has in turn been renamed to "Fogcutter". The reason is that "ScrewPile" is just a bad name, that looks and sounds ugly unless you're one of the 15 people in the world who knows what a "screwpile" lighthouse is.)


Welcome! Some of you may have known this project under its old name OpenQabal. We've recently decided to rename the project amidst some other dramatic changes, and this new blog is now the home for news and updates about the project.

If you made it here by accident, or don't know exactly what ScrewPile is, let us explain:

What is it?



ScrewPile is an umbrella project, sponsored by Fogbeam Labs, which is building a suite of powerful, open-source tools for knowledge management and collaboration. ScrewPile was formerly known as OpenQabal but has been renamed, as part of an effort to develop a consistent naming pattern for related projects.

Why "ScrewPile?"



A Screwpile is a particular type of lighthouse. Fogbeam'ers like lighthouses, so we're using lighthouse related terms for all of our open source activities.

Tell Me More



The 65,000 foot overview description would go something like this:


"ScrewPile is an open-source suite of APIs, components and applications - driven by the principles of federation, composition, open protocols, and open standards - for building and enabling intelligent enterprise applications for collaboration, social-networking, knowledge management and discovery, organizational learning, Information Retrieval and decision support."


ScrewPile proper, then, is an "umbrella project" or over-arching structure for sub-projects that handle different parts of this vision. Think of how Glassfish has become an "umbrella" project for a series of related projects: OpenMQ, OpenESB, SailFin, Portal Server, etc.

With ScrewPile as the overall encompassing framework, sub-projects will deal with provide various APIs and/or applications / subsystems that are part of this overall "intelligent application" vision.

Subprojects will deal with things like: an API / system for managing tags, recommendations engine, mechanism for dealing with voting/ranking things, something for managing a social graph and allowing queries against it, etc.

Of course, as before, in a lot of areas existing open-source code exists to do these things. In that case, we may (within the letter and spirit of the respective licenses) just "borrow" existing code, possibly wrapping or modifying it to fit the model of what we're doing here. Other bits will have to be written entirely from scratch, and that's OK.

Tell Me About These Subprojects



Well, here's what we think we know about them so far:


  • Neddick - An interface that builds on the APIs for tagging, ranking and recommending items, to provide a platform for sharing and discovering useful links, documents, people, etc. What we have right now is pretty simplistic, but there's a LOT of room for growth in this.


  • Quoddy - a sort of "mini Facebook" like social-networking interface. Builds on the APIs for social-graph management, activity-stream, activity profiling, tagging, etc. Provides the front-end for managing connections and for letting users provide information about themselves, their interests, etc. But unlike Facebook, no silly Pirates vs. Ninjas or Farmville stuff.

  • Heceta - This may not actually come into existence as a standalone project; but the general vision is a search engine that leverages all of the various bits of information from Neddick, Quoddy, and "TBD" to provide better / deeper / more insightful search results than you can get from simple document content analysis. Intranet search in the Enterprise usually sucks, largely because page-rank type algorithms don't work well due to the lack of links between documents. But by supplementing the content analysis with scoring based on tags, social graph connections, activity-stream information, etc., it should be possible to do a much better job. This is not, by the way, a totally novel idea. It's something people are referring to as Social Search.

  • GraphEngine - as before, an API for storing and managing the "social graph stuff." Doing this on a large scale is still a problem, and I'm intrigued by the idea of using an incremental evaluation system approach for this, but haven't done much on this yet.

  • ProfileEngine - name says it all, really.

  • RecommenderEngine

  • ActivityEngine

  • TagEngine

  • Etc.



Of course since this is all intended for an enterprise setting, a big focus will be on integrating with other systems (see the point about "open protocols" and "open standards" above).

Previous discussion of Neddick (formerly code-named "Project Shelley") mentions discovering documents and people, despite the screen shots only showing stuff about links so far. That's where integration comes into play... part of the vision is to integrate with, for example, a document management system like Alfresco, a forum system like JForum, a groupware / calendar system, a HRM system like OrangeHRM and/or a social-networking application like Quoddy (formerly code-named "Project Poe").

That, of course, also plays into the vision for Heceta, which is all about searching across all the different domains, and using the knowledge aggregated across all of them, to enhance our search capability.

Get involved by visiting the project page on Google Code.

Syndicated 2010-07-08 03:01:00 from ScrewPile Dev

8 Jul 2010 (updated 20 Aug 2012 at 02:50 UTC) »

OpenQabal renamed, development moved, etc.

(edit: everything below is true, with the addendum that "ScrewPile" has in turn been renamed to "Fogcutter". The reason is that "ScrewPile" is just a bad name, that looks and sounds ugly unless you're one of the 15 people in the world who knows what a "screwpile" lighthouse is.



As we get very (very) close to a release of "The project formerly code-named Project Shelley," big things are at hand in OpenQabal world. First... the project is renamed. Say goodbye to "OpenQabal" and hello to "ScrewPile."

Why ScrewPile?


A Screwpile is a particular type of lighthouse. Fogbeam'ers like lighthouses, so we're using lighthouse related terms for all of our open source activities.


Also, development has been moved from the old Java.net site and onto Google Code and Github. The new ScrewPile Project on Google Code is already available for your perusal. A New ScrewPile Dev blog is available as well. GitHub repos are coming soon'ish.

Why Google Code? And why Google Code *and* GitHub?


Google Code is just a little easier to work with. The project pages can be edited wiki-style and it has nice integration with Google Groups, etc. And since all of these big changes are coming, now seemed like a good time to switch. As to why both GC and GitHub... because Git is the future, and we expect the Git repo(s) to be the main basis for development, with code pushes to the Google Code SVN repo as a convenience for people who don't know Git, don't have access to Git, etc.


The other big news... "Project Shelley," "Project Poe" and "Project Collins" all have real names now! Say hello to Neddick, Quoddy and Heceta respectively.

Why "Neddick," "Quoddy," and "Heceta?"


Because we like lighthouses. Neddick is named after the famous Cape Neddick "Nubble" Lighthouse, Quoddy after the West Quoddy Head Ligthouse and Heceta after the Heceta Head Lighthouse.


There are still a few things to be worked out over the next day or two, but we expect to be totally up and running on the new system(s) very soon, and the first code pushes from the new codebase will be out very soon. Stay tuned...


And as always, follow @ScrewPile on Twitter for super handy news blurbs and updates.



Syndicated 2010-07-08 02:29:08 (Updated 2010-07-08 02:44:18) from openqabal

Capability Case #2: Technology Radar

Following on from yesterday's post about Project Shelley Capability Case #1: Collaborative Filtering for Information Retrieval, here is the next detailed capability case for Project Shelley Capability Case #2: Technology Radar. Also available in (pdf) and (odt) format.


Name:

Technology Radar

 

Intent:

              Identify technological developments - which may present either a threat to the enterprise, or a groundbreaking new opportunity - as early as possible. 

 

Description:

New technologies are being developed at a dizzying pace.  Worldwide, private enterprises, academic researchers, and open-source hackers are all constantly pushing the envelope, developing new approaches and tools.   Some of these advancements may represent a huge threat to your organization, perhaps by enabling a competitor to cannibalize your existing business model with a much less expensive alternative.  Others may represent an opportunity to break new ground with products, product features, or services that can represent sizable new revenue streams. It is advantageous to identify these advances as soon as possible, in order to out maneuver the competition and take maximum advantage of new developments.

 

As Downes and Mui point out in their book Unleashing the Killer App, this kind of awareness requires a technology radar consisting of a fat pipeline, a sensitive radar screen and sophisticated intelligence.

 

Solution Story:

              At MegaCorp, developers of the market leading Flozzit product, leaders are constantly jousting with rival HyperCorp, each striving to release the most advanced product in order to steal customers from the other.  Recently, HyperCorp has released a multiple new versions with features that no one at MegaCorp had considered, or believed possible at the time.  After the most recent release, MegaCorp leaders dug in and discovered that HyperCorp had integrated advanced technology developed by researchers at Miskatonic University.  “Why,” asked MegaCorp CEO Howard Phillips, “did we not know about this sooner? This is actually a better fit for our product..  if we had done this first, we could have taken a huge chunk of HyperCorp’s market share, instead of letting them jump further in front of us”  No one had an answer.

              In order to address this lack of awareness of emerging technologies, MegaCorp decide to implement a Technology Radar.  An “emerging technologies” channel is created, where every member of the organization can submit links to documents, articles and news-feeds that touch on technologies related to MegaCorp’s industry.  Users throughout the organization vote, tag and comment on each submission, allowing the collective intelligence of the organization to filter the less important items, while pushing the key ones to the top.  Product Managers and executives begin to make browsing the latest ‘top items’ on the channel a routine habit... and some users configure the system to send them a dynamic alert via instant messaging when an entry reaches a certain score.

              A few months later, the Flozzit Product Manager receives such an instant message... the link is to an article published by Arkham University, announcing the development of a  new algorithm which solves a problem that MegaCorp engineers have been struggling with.   AU has released the source code under a permissive open-source license, and MegaCorp begin integrating the new approach, and also recruit two of the students from AU who worked on the project.

              Using the new technology, MegaCorp are able to deliver a new release of Flozzit with several features which they believe that HyperCorp cannot match.  Amazingly, the new HyperCorp release comes out six weekslater, and is almost totally equivalent to the new Flozzit.

CEO Phillips talks to his mangers and explains why he’s happy with developments; “We weren’t able to leap-frog them this time... but if we hadn’t rolled that new stuff out when we did, their new release would have been a dagger into our heart.    Now we’ve shown them, and the market, that they aren’t always the ones on the forefront of technical advancements.  And the two new guys we hired from Arkham are already hard at work on some stuff that’s going to blow everybody away.”

             

Vintage:

Mature Commercialization             

 

Challeges:

Corporate culture which fosters a “Not Invented Here” syndrome. 

Lack of incentives for participation in the system.

Lack of belief in the utility of the system.

Lack of participation in the system by executives and other decision makers.

 

Forces:

              TBD

 

Business Results:

              Better awareness of technological advances which are significant to the organization.                            Ability to gain early mover advantage over competitors by incorporating advances              

sooner.

Lower risk of being one-upped by the competition with a significant technical             

advancement.             

 

Capabilities:

              Share links to web-sites, documents and other items of interest

              Categorize links by topics using channels

              Tag links with specific keyword

              Rank items by voting them “up” or “down”

              Search and filter by topic, keyword, and/or score

              Sort view by various statistical measures, such as “all-time score”, “hotness”, and              

“controversiality.”

Dynamic alerting, via email, instant messaging, etc.,  when items reach certain thresholds.

 

Typical Use Scenarios and Guidance:

              A technology radar is established to pull in information from many disparate sources:

              RSS feeds, Twitter streams, email lists, and user submitted links to websites, documents               and articles.  Collaborative filtering through collective intelligence is used to filter the                             lower value submissions, while ensuring the relevant information gains visibility.               

Employees through the organization view the radar, through the “emerging technologies”              

channel and take advantage of the information. 

 

In some cases this may represent a “bottom up” scenario, such as an engineer finding an interesting new library which enables a feature the engineer likes... he quickly knocks out a prototype, shows it to senior management, and it is eventually adopted into a product release.  In another case, this may be a “top down” scenario, where a senior leader discovers a new technology, and issues a mandate that R&D investigate it’s applicability to their product.

 

Applicable Technologies:

              Fogbeam Labs “Project Shelley”

Other corporate knowledge repositories (blog servers, forums software, document              

management systems, HR management systems, etc.)

Existing Data Warehouses / Databases / Knowledgebases

External information sources (web pages, databases, etc.)

 

Implementation Effort:

              TBD

 

Integration:

              Project Shelley can easily integrate any knowledge source which can be accessed via

HTTP and which exists in a format which can be parsed into text tokens for indexing by              

Lucene.  Where text extraction is not possible, location through metadata is still possible (ex, mp3 audio files, video, etc).

 

 

Integration Mechanism:

              RSS feeds, HTTP, OpenSearch

 

Integration Status:

              TBD

 

Syndicated 2010-06-12 17:02:14 (Updated 2010-06-12 17:03:15) from openqabal

42 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!