With the recent release of MindTouch 2009 some have noted we’ve dropped “Deki” and “DekiWiki” from the product name. This was an intentional omission. We’ve thought long and hard about this and we are convinced this is in the best interest of “DekiWiki” the open source project and MindTouch, Inc the company. It has been clear for some time that MindTouch users, MindTouch customers, journalists and analysts are consistently being confused by MindTouch product naming. As such, in order to alleviate confusion we’re simplifying for the sake of our users, developer community and customers. Initially it will take a little getting used to, but this will be in everyone’s best interest.

Over the coming weeks (and months) MindTouch, Inc will be making changes to www.MindTouch.com and the MindTouch community to reflect this change. It will take longer for MindTouch, Inc to make all the required name changes in the source code of our flagship product. I hope you’ll be patient with us as we make this important transition. I’m confident the naming convention we’re soon to employ will make MindTouch, Inc and the software we develop significantly easier to understand from a product perspective. In effort to clarify further, allow me to provide a rough sketch of MindTouch products and technologies:

MindTouch Core is the free and open source (gratis and libre) core of MindTouch software, the most popular wiki and collaborative portal ranked in the top open source projects in the World and ranked #1 in collaboration by Sourceforge.net. MindTouch Core is licensed under GPL v. 2 and is most suitable for developers, technical enthusiasts and for use in non-critical environments. It has most of the features of MindTouch Standard and MindTouch Enterprise, but lacks official MindTouch, Inc support and many enterprise tools for utilizing MindTouch beyond wiki collaboration.

MindTouch Standard is an enterprise class wiki and collaboration platform for business automation that meets the needs of workgroups and medium sized organizations. MindTouch Standard is production ready, officially supported and is the minimum requirement for using the MindTouch Desktop Suite, database adapters, CRM adapters, charting tools, full featured LDAP and Active Directory module and more…. Moreover, this build is available under a shared source (non-GPL) license and includes indemnity. Pricing is based on number of users.

MindTouch Enterprise offers the most robust enterprise-grade capabilities and scalability for medium sized to large organizations. MindTouch Enterprise is intended for large scale, high traffic, unlimited user deployments and supports multi-tenant, clustering and includes additional single sign on tools. Also, as is the case with Standard, this build is available under a shared source (non-GPL) license and includes indemnity. Pricing is based on number of tenants.

Some important odds and ends. MindTouch DekiScript will retain its name. DekiScript is a scripting language that provides a safe and secure mechanism for developing automation, custom workflows and enterprise mashups within MindTouch. MindTouch Dream is a .NET REST micro-server and programming framework for developing lightweight decoupled web-services, which is a technical way to communicate it’s a great tool for developing distributed software applications, or what is more commonly referred to as  cloud software. This too will keep the same name.

In the coming weeks MindTouch.com will be undergoing some major improvements. Specifically, we’re improving product communication, site navigation, the solutions page, adding a partner page(s) for new partners and more…. Most of the work being done on the website is based on recommendations from MindTouch community members and customers. If you have suggestions or questions please feel free to post comments here or email me directly (AaronF at MindTouch dot com). Thanks for all of your input and enthusiasm I’m thrilled that users and customers consider MindTouch to be their software and their company and not just an external entity.

In conclusion, I want to communicate a critically important point: MindTouch, Inc will always release an open source version of our software, keep open code repositories, public bug tracking, specs, roadmap, etc…. MindTouch Core is the realization of this commitment. In general terms, MindTouch, Inc will develop and differentiate the Standard and Enterprise editions from MindTouch Core with features that enable greater scale, management, desktop tools and portal-like capabilities such as enterprise automation and integration. MindTouch, Inc is committed to the principles and freedom open source development and distribution affords.

Every so often, I get the question of “why would anybody want to store XML in a wiki?” Granted, this question is usually brought up by a competitor rather than by a customer. At first brush, XML just makes things more complicated, but this perception quickly dissipates as your collaboration turns into automation turns into workflows. In this post I share some insights into why MindTouch Deki is built the way it is.

Most wikis use wikitext as markup language. Wikitext is what made wikis popular: it’s fairly easy to learn by semi-technical people, it’s fast to edit, and it doesn’t require much of a user interface. One could say that a wiki without wikitext is not a wiki - since the origin of the term “wiki” is the Hawaiian word “fast.”

MindTouch Deki, on the other hand, uses XHTML–an XML format for content. XML is tedious to edit by hand, it’s verbose, and hence requires a user interface to be usable. It is also fairly complex to combine contributions from multiple authors and highlight changes between versions.

At first brush, one might wonder why choose XML over wikitext? The reality is that wikitext was a great start for the open collaboration revolution - and I do mean revolution, but more on that in another post. But wikitext has its problems. It’s not a standard. Different wiki vendors use different markups. Sometimes, a wiki even makes the markup selectable. That’s not good for promoting uniformity and training users. Wikitext makes simple operations simple and it makes advanced operations nearly impossible. In the end, we have to recognize why wikitext was invented. Wikitext allowed validation of the hypothesis that open collaboration works, without requiring lengthy user interface development. That hypothesis has been validated: open collaboration not only works, it works amazingly well! This was the goal and it was achieved. Usability was not a goal. Now, it’s time to look at what was sacrificed to get us there.

The first victim of wikitext was the WYSIWYG editor. Nobody wants to format content using markup, even wikitext markup. Once formatting becomes a concern, wikitext is starting to show it’s limitations. Regardless of how many resources are being poured into creating a wikitext-enabled WYSIWYG editor, such editor will always be second rate when compared to a HTML editor. Why? Because HTML is an industry standard with lots of competition to create the best HTML editing experience possible. It’s simple Darwinism. Modern browsers support HTML editing. Microsoft Word supports HTML editing. Countless other applications support HTML editing. Why discard all these great tools and start from scratch?  At the end of the day, you would need to replicate everything that HTML already does. That doesn’t sound right.

In contrast, relying on existing standards has many benefits. For example, MindTouch Deki now uses fckEditor for WYSIWYG editing–don’t let the name distract you from this otherwise fantastic editor. Before fckEditor, Deki used Xinha as editor. In the future, Deki may use something else, be it written in JavaScript, Flash, or even Silverlight. As long as the editor supports HTML, the option will be on the table. It also means companies which have built custom user interfaces for Deki, such as Shelfari, can select the editor that best fits their needs. Because HTML is a standard and Deki is built using XHTML, our users have more choices in how they want to interact with their content. And that’s a pretty good thing.

The second victim of wikitext is interoperability. Even if wikitext were a standard, it would still be confined to wikis. What about all the other applications out there? What format should they use to extract or update information in a wiki? Would everything need to become wikitext enabled? This approach doesn’t seem reasonable. With XHTML, you get the best of both worlds. First, you get all the benefits of versatile HTML editors, and second, you get all the powerful tools that have been created for XML. For example with XPath, you can locate and extract exactly the piece of information you want. And with XSLT, you can format this information in anyway you like. XML tools are found in all programming language and enterprise systems. Using XML gives a system a lingua franca that forms the foundation for interoperability. That’s why we made sure that the Deki API provides access to all functionality in XML, including the content of pages.

The last point is about the benefits of native support for XML - and JSON, another popular interoperability format. Once you design an application to store everything in XML and you give it scripting capabilities, you implicitly create something much, much larger. For example, the “other” applications I referred to in the previous paragraph are now simply scripted wiki pages: wiki pages that can read other wiki pages, locate and extract information, and then present this information in an augmented way. This capability is profoundly important: when pages can automate the synthesis and presentation of information, you get a great reporting tool. When these pages can be reused themselves as XML sources, you get a formidable business tool. This ability is what made spreadsheets the #1 business tool. With Deki, this capability is now unleashed unto networks of individuals rather than confined to their individual desks.

The ability to retrieve and process XML/JSON is an integral part of DekiScript, Deki’s built-in scripting language. DekiScript enables users to create composite pages using content from the wiki as well as from web-services. New web-services for business applications and online data emerge every day–ProgrammableWeb is a great resource to learn about them. Deki is designed to take advantage of these and put their power into the hands of your users. This kind of capability would not be possible if Deki had not been designed from the ground up to be XML-based. To get a sense of what is possible, visit our DekiScript forums. I’m amazed every day about what our community is building with it.

In short, the benefits of using XML as the de facto data format and making it core to the platform yields immediate rewards. This is part of our web-oriented architecture and I personally believe it is one of the strongest reasons why Deki fits so well with business applications and online communities. After all, no man is an island, and neither should your wiki.

Tutorial, Code and Demo - Click Here

I’ve been working with a great deal of DekiScript recently and I haven’t really had much time to “show off” any of my developments. Well, just this week I completed a new DekiScript dropdown menu and it’s quite nice so I figured I’d share.

The dropdown menu was developed using a combination of DekiScript and JQuery. It is very easy to implement and doesn’t require using any extensions. Simply just create a new template and paste in the provided code. The template then can by included on desired pages to provide an additional layer of navigation to your community.

The menu that is generated from the template displays two tiers of navigation and originates from the Deki root by default. Alternatively you can specify a path either statically or dynamically using DekiScript to identify where the navigation should originate from.

The code can be cleanly separated into two portions, DekiScript which handles the markup and Jquery which takes care of the CSS. Lets first take a look at the DekiScript as a whole and then I’ll step through individual portions of the DekiScript code.

{{
var langpath ="/";
if ($path) {
let langpath=$path;
}
var langdir = wiki.getpage(langpath);

var topnav = langdir.subpages;
var subnav;
var navhtml;
var tophtml;
var subhtml;
var dropicon;
var topselect;

foreach(var top in topnav) {
  let subhtml='';
  let subnav = top.subpages;
  let dropicon='';
  let topselect='';

  foreach(var sub in subnav) {
     let subhtml..=('<li class="'..sub.name..'">'..web.link(sub.uri,sub.title)..'</li>')
  }
  if (#subnav > 0) {
     let dropicon='<span class="dropicon">v</span>';
  }
  if (string.contains(page.uri,top.uri)) {
     let topselect=' selected ';
  }

let navhtml..=('<li class="'..top.name..topselect..'"><span>'..web.link(top.uri,top.title)
..dropicon..'</span><ul>'..subhtml..'</ul></li>');
}

web.html('<ul id="DWdynnav">'..navhtml..'</ul>');
}}

Now lets break it down into smaller DekiScript chunks to take a look at what each piece is doing. The first part of the DekiScript is responsible for defining the path that the navigation should originate from. I used var langpath ="/"; to set the path default to your wiki homepage. $path is a template variable and is optional. If you are going to provide a path (discussed at the bottom of this blog post) you will do so when you call the template from the page that will display the menu. Lastly I need to work with the page object so I can access the properties and subpages to map out my menu. This is done by using var langdir = wiki.getpage(langpath);. Wiki.getpage returns a page object so if I later needed to I can access properties of the navigations origin page using something such as langdir.title or langdir.author.

var langpath ="/";
if ($path) {
let langpath=$path;
}
var langdir = wiki.getpage(langpath);

The next section is fairly simple. First I am finding out what pages are going to make up my top nav or the 1st tier of the dropdown menu. This is done by accessing the properties of langdir as mentioned in the previous section. You can see that I use var topnav = langdir.subpages; which will set topnav to a map of page objects which I will loop through soon to build my structure. After that I have to define a series of variables that are used to generate the navigations, HTML, CSS and the dropdown icon.

var topnav = langdir.subpages;
var subnav;
var navhtml;
var tophtml;
var subhtml;
var dropicon;
var topselect;

So here’s where it gets a little trickier. To start off I need to loop through each item from the topnav so I setup my foreach loop using foreach(var top in topnav). As I start looping there are some variables that need to be set, they may have different outputs based on the dropdown content.

The first and most important variable I have to set is the dropdown pages. I do this by using let subnav = top.subpages; which will again return a map of page objects which I can later loop through to output the subpages. The other variable are just being reset.

Now that I know the dropdown pages (subnav) I can begin to generate the HTML that will be used to construct the navigation. As I loop through the subnav pages using foreach(var sub in subnav) I am appending new HTML to the subhtml variable which looks like this let subhtml..=('<li class="'..sub.name..'">'..web.link(sub.uri,sub.title)..'</li>')

After I have generated my subnav I need to differentiate my topnav menu items with a subnav from the topnav menu items with no subnav. Basically, if a topnav menu item does have subpage I want to display a little down arrow to let users know. This is done by using if (#subnav > 0). The # will return a count of the objects in the subnav variable, if any. If the topnav does have a submenu I add in a down arrow using let dropicon='<span class="dropicon">v</span>';.

The next part is not really necessary but I added it in regardless. Using if (string.contains(page.uri,top.uri)) I am comparing the topnav page URI’s to the location of the page the the user is on. If their is a match I output let topselect=' selected '; which is later used in the topnav class. This allows users to know where they are relative to all of the pages in the dropdown menu.

The last part simply pulls all of the previous pieces together to construct the final HTML that will be used for the menu. You can see that I am using some DekiScript page properties such as top.name and top.title and I’m also using some DekiScript functions such as web.link. Lastly I’m placing my variables as need throughout the HTML: topselect, dropicon, subhtml.
let navhtml..=('<li class="'..top.name..topselect..'"><span>'..web.link(top.uri,top.title)
..dropicon..'</span><ul>'..subhtml..'</ul></li>');

foreach(var top in topnav) {
  let subnav = top.subpages;
  let subhtml='';
  let dropicon='';
  let topselect='';

  foreach(var sub in subnav) {
     let subhtml..=('<li class="'..sub.name..'">'..web.link(sub.uri,sub.title)..'</li>')
  }
  if (#subnav > 0) {
     let dropicon='<span class="dropicon">v</span>';
  }
  if (string.contains(page.uri,top.uri)) {
     let topselect=' selected ';
  }

let navhtml..=('<li class="'..top.name..topselect..'"><span>'..web.link(top.uri,top.title)
..dropicon..'</span><ul>'..subhtml..'</ul></li>');
}

If you were to leave this output without the additional Jquery code you would have a bulleted list of a page and it’s subpages. Now for the sanity of the readers I’m not going to step through Jquery. All you should know is that it is completely customizable and I created color and style variables at the top to easily modify the look and feel of the menu. You can view a full output of the DekiScript SOURCE with the Jquery at http://wiki.developer.mindtouch.com/User:Howleyda/DekiScript_dropdown_menu/Source. To utilize this code simply copy and page the content into a new template on your Deki.

The very last part which is most important is including the template in a wiki page.

If you want to show the root menu use {{template.DropDown()}}

If you want to specify a path use something like {{template.DropDown{path:page.path} }} or {{template.DropDown{path:"/DekiScript"} }}

Thanks for reading,

Damien Howley
@DamienH

View live demo

One of the best parts about MindTouch Deki is its extensibility. There are many avenues experienced and novice developers can take in order to integrate new functionality into MindTouch Deki. From native compiled C# extensions to remote XML-RPC extensions, the possibilities for adding new Deki functionality is only limited by the imagination of a developer. Going forward, I’m going attempt writing mini-tutorials showing you just how easy it is to “develop on the platform” and get your developer juices flowing.

While using Deki, and in my own travels of our forums, I’ve noticed that users want to search. More so, they want to power search. Often times, as a UI developer, we don’t have enough hours in the day to implement all the functionality that Deki’s REST-based API exposes. The search API, powered by Lucene, supports many different modifiers for winnowing and expanding search results, however, the UI purports that a user should type those in manually. Ergo, a good excuse to prototype an advanced search extension with DekiScript and JavaScript.

After a few hours of hackery, I came up with the MindTouch Deki Advanced Search extension. It uses JavaScript to generate a Lucene query string from form inputs and DekiScript to fetch search results. All in all, the longest part of writing the extension was this blog post and the associated tutorial. Without boring the non-developers much more, I conclude with a link to the complete tutorial and extension. There you can find the full writeup on how the extension was built and how you can use it on your own Deki.

Keep a lookout for more “developing on the platform.” The next installment promises to utilize DekiScript content transformations; powerful and, mostly, untapped functionality. /end cliffhanger

For the upcoming 8.08.1 release we’ve added a bit of new DekiScript syntax to make code easier to write and allow more control over the flow.

Multiple variable declarations and declarations without a value

The old syntax for var required just one variable name and an initial value, like var x = 123. With the new syntax, multiple variables can be declared at once and variables can be declared without a value. This means that all of these are now valid:

var x;
var x,y;
var x = 1, y =2, z=3;
var x = 1, y, z;

Single statement blocks do not need curly braces

Both if/else and foreach required their statements to be enclosed  in { ... }, even if there was only a single statement. A by product of this was a complicated and hard to read syntax for if/else-if/else blocks, since the second if/else effectively was the statement block of the first else, resulting in statements like this:

if( x == 1 ) { "1"; } else { if(x == 2) { "2"; } else { "3"; } }

With the new syntax, curly braces can be omitted if there is only a single statement in the block.

if( x == 1 ) "1"; else if(x == 2) "2"; else "3";

The same simplification works also applies to foreach.

Foreach flow control with break and continue

Another addition for foreach is the introduction of break and continue control flow statements. The break statement will immediately terminate the current foreach loop block and continue executing the code that follows the foreach block. The continue statement on the other hand will terminate the loop block and restart it with the next iteration value.

foreach (var x in [1,2,3,4])
{
  x;
  if( x == 2 ) continue;
  else if(x==3) break;
  ".";
}
"x";

This code with produce the output “1.23x“.

Introducing the switch statement

The final addition to DekiScript for this release is the switch/case statement. So, while if/else-if/else is more concise now, for flow control relying on picking among many paths based on an expression, switch/case offers a much better syntax. The easiest way to illustrate switch/case is with an example:

var x = 2;
switch(x)
{
  case 1:
    "one";
  case 2:
    "two";
  case 3:
  case 4:
    "bigger than 2";
  default:
    "bigger than 4";
}

Here, we take a number and try to emit a string appropriate to the number. The output for this particular bit of code would simply be “two“. The case for 3 illustrates fallthrough, i.e. in our switch implementation there exists implicit fallthrough, but only if the case does not have a block of its own. Therefore the cases for 2 and 3 return the same value. Finally we have the special case of default, which will trigger if no other case matched. default is not required.

We hope these additions make it even easier to create custom dynamic content with dekiscript, so check them out once 8.08.1 is released and let us know how you like them.

The extension I’m focusing on this week is TinyURL which generates a shorten url for your MindTouch Deki pages. This is beneficial when you have a deep hierarchy and want a quick url to send to people. There is something unique about this extension, you don’t have to install anything. This extension was created using DekiScript.

To invoke the extension, paste the following code in a MindTouch Deki page:

{{ web.link(web.text(uri.build("http://tinyurl.com/api-create.php", _,
{  url: page.uri }))) }}

It will turn this:
http://wiki.developer.mindtouch.com/DekiScript/FAQ/How_do_I…_Generate_a_TinyURL_for_my_pages_automatically%3f

into this:

http://tinyurl.com/58j9ea

This script is dynamic, so it will create a new url for each page it is pasted on without having to change anything.

I encourage you to read more about DekiScript and how it can enhance your Deki install.

If you have any questions please feel free to contact us or post a comment.

This week I’m going to focus on a lesser known set of built in Meta Tag extensions for MindTouch Deki. The Meta Tag extensions allow you to add information into the header of MindTouch Deki like keywords, description, author information, and more. I’m going to focus on a couple of common use cases that Meta Tags are beneficial for:

In support I’m often asked the following question: “I want to add my site to Google Webmaster Tools but they need me to verify that I own the site.” Google gives two options to do this 1) upload an html file into the root directory or 2) add a custom Meta Tag to the site header. Uploading an html file or adding a keyword typically requires FTP or Shell access. With MindTouch Deki we simplify it by allowing you to add custom Meta tag extensions through the WYSIWYG Editor.

In the case of adding a Meta Tag so that you can have ownership of a site you would do the following:

1. Edit your MindTouch Deki HomePage and click on the Cog icon to open the Extension dialog
2. Click on Built in Functions and scroll down to meta.custom
3. The name is the meta name that Google includes, something like verify-v1
4. The content would be the long alpha numeric string from the Google code
5. Insert it and save the page, then go back to Google and verify

The actual extension will look something like this (content is skewed):

{{ meta.custom{name: "verify-v1", content: "fdshjfhdsjkhfjkdshjkfdsafkdshakfhdksa543245"} }}

Another good use for the Meta Tags is to add keywords and descriptions for your MindTouch Deki pages. This helps with SEO of your MindTouch Deki site. You can do so by going into the Extension dialog again through the editor and selecting meta.keywords or meta.description under the Built In category. This can be done on a per page basis.

Here is an example of a meta keyword and description DekiScript:

{{ meta.keywords{content: "blog, testing"} }}
{{ meta.description{content: "This is a test page about meta tags"} }}

This functionality is currently available in all MindTouch Deki downloads Release 1.9.1 and higher and will be available in Wik.is after the next upgrade which will be coming out in the next couple of weeks.

To read more about the supported Meta extensions in MindTouch Deki check out the Meta Functions specs.

If you have any questions please feel free to contact us: http://wiki.mindtouch.com/support

Until now the only portion of a page that has been editable by the user is the content inside the editor. Logically this makes sense, however, there are times when a user or administrator may want to add additional content to the skinning template*. For instance a user may want to add advertisements, navigations, widgets or some custom html. Such functionality has been available since November, 2007 but was fairly basic. Users could add site-wide content into numerous different custom HTML areas and were limited to HTML and client side scripting languages.

With our latest improvement (8.05.1) users can now designate custom skin content by assigning a page template** to specific skinning regions. This process offers two noticeable benefits. First, custom content can now be injected on a per-page basis. Second, and most importantly, custom content can now utilize DekiScript which means that both server-side and client-side functionality is acceptable. Another extremely useful benefit of using DekiScript for custom skin content is the ability to script per-user functionality.

In order to support skinning template targeting you need to make some minor modifications to your Deki. First you need to define which portions of your Skinning Template can have Deki content injected into them (for security reasons). To do this you need to crack open LocalSettings.php and add the following line:

$wgTargetSkinVars = array('customarea1', 'customarea2', 'customarea3',
'customarea4', 'customarea5');

By adding the $wgTargetSkinVars to LocalSettings.php your simply granting permission for the listed Skinning Variables to be overwritten with injected Deki content. In the above example you can see that I opened up all the custom areas in a skinning template. If you’re using Fiesta these custom areas are the same as the custom HTML areas that are found in Control Panel > Visual Appearance > Custom Site HTML.

Now that you’ve updated LocalSettings.php you can go to your Deki and start injecting content. To start lets first create the content that is going to get injected. Navigate to Tools > Templates and create a new template called ‘PageTemplateName’. Add some generic text such as “MindTouch Deki is awesome”, save and then navigate to your Deki homepage. Now click edit on your Deki homepage and add the following DekiScript:

{{ wiki.template("PageTemplateName", nil, "customarea1") }}

Using the DekiScript above you’ve injected your Page Template into customarea1. Now you can take this example a little further by adding some DekiScript into your Page Template. Navigate back to Tools > Templates > PageTemplateName and click edit. Add some of the following examples:

{{ web.link(user.uri,'Take me to my page') }}
{{ wiki.contributors(nil, 3) }}
{{ feed.list('http://feeds.feedburner.com/mindtouch?format=xml',5) }}

I’ve been experimenting with this new approach a lot recently. In fact I have created two custom templates that take full advantage our new skinning capability. In both cases I was able to easily add powerful functionality to the templates with very little code. As I continue to experiment with new approaches to skinning I’ll be sure to keep everyone up to date.

Thanks

Damien
DamienH[at]mindtouch.com

In the annals of time certain weapons have stood out, surpassing all others in strength and use. Thor swung his great hammer to smite those who stood in his way. Arthur pulled Excalibur from the stone and lead humanity to Avalon. And Beatrix Kiddo beat all odds to rescue her daughter and “Kill Bill” with the aid of the Hattori Hanzo sword. Yet now, a new weapon has been forged and hardened in the blazing fire of a bright mind to cut through the most perilous environments of our modern world: the office. The name of this weapon: MindTouch Deki.

Wednesday the 16th of July 2008, MindTouch will be hosting the first ever Deki-Con. Deki-Con is a rare chance for the student to learn from the masters of the Deki Way. Deki-Con is open to all who want to make their Deki skills fierce like tiger. MindTouch will provide food to strengthen mind and body, and libation to celebrate the completion of training.

Sensei Steve, creator of the Deki way, will be performing a dangerous exhibition on how to wield DekiScript to create dynamic pages in MindTouch Deki.  If the students prove worthy; Sensei will share his wisdom into the occult art of XML extensions to achieve true enlightenment.

Master Damien, a 3rd degree black belt in the art of CSS, will guide the students through the elegant moves of the Fiesta architecture completing the lesson with training on the lightening-fast skinning, known as the Fiesta Form.

To all students of the Deki Way, near and far, come join us and make your Deki skills strong! The masters will only take a few students. Take action now and reserve your place.

What: Deki-Con (Hand-to-Hand Developer Training)

When: Wednesday July 16th

Start Time: 6:04 PM

Where: MindTouch Dojo 555 W. Beech St Suite 501 San Diego, CA 92101

Cost: Free

RSVP Required: http://dekicon.eventbrite.com/

For additional information or questions contact: events AT mindtouch DOT com