Open Menu

Synergex Blog


CodeGen 5.2.1 Released

By Steve Ives, Posted on August 24, 2017 at 2:10 pm

We are pleased to announce the release of CodeGen 5.2.1 which includes several new features that significantly extend the possibilities for what can be generated. The core goal for this release was to introduce new features that make it possible to sub-divide the processing of large loops into smaller units of code, and by doing so make it possible to achieve new things, especially when working with very large structures.

For example, the reference code that demonstrates how to implement the replication of ISAM data to a relational database (https://github.com/SteveIves/SqlReplicationIoHooks) previously had a restriction that it could only deal with files (tables) with up to 252 fields (columns). The underlying reason for this related to the maximum number of arguments that can be passed to an external routine, %SSC_BIND in this case. The restriction of 252 available data parameters to %SSC_BIND meant that bad code would be produced for any structure with more than that number of fields. Now however, using some of the new features in CodeGen 5.2.1, the template has been re-structured so that %SSC_BIND will be called multiple times if necessary, removing the previous restriction.

But that’s just one example, there are doubtless many more. Here are the release notes for the new version:

  • We added several a new generic expression token <IF COUNTER_n_op_value> that allows you to write conditional template code based on testing the current value of the two internal template counters against a simple numeric expression. Here is an example of using this new expression:
<IF CODEGEN_COUNTER_1_EQ_10>
Code to include for every 10th item
</IF>
<IF TOTAL_ITEMS_LT_50>
Code for a small number of items.
<ELSE>
Code for a larger number of items.
</IF>
<REQUIRES_CODEGEN_VERSION>5.2.1</REQUIRES_CODEGEN_VERSION>
  • We made a minor correction to the documentation of the -f l command line option. The documentation previously stated that this option caused fields marked as “Excluded by Language” to be EXCLUDED from field loop processing, but actually such fields are excluded by default. The -f l command line option actually suppresses this behavior, causing such fields to be INCLUDED in field loop processing.
  • This version of CodeGen was built with Synergy/DE 10.3.3c and requires a minimum Synergy run-time version of 10.1.1.

The latest version of CodeGen can always be downloaded here.


CodeGen 5.1.7 Released

By Steve Ives, Posted on February 7, 2017 at 10:25 am

We are pleased to announce that Professional Services has just released CodeGen 5.1.7. The main feature of the release is the addition of experimental support for generating code for the MySQL and PostgreSQL relational databases. Developers can use a new command line option -database to specify their database of choice. This causes the SQL-compatible data types that are injected by the field loop expansion token <FIELD_SQLTYPE> to be customized based on the chosen database. The default database continues to be Microsoft SQL Server.

Before we consider support for these new databases to be final we would appreciate any feedback from developers working with MySQL or PostgreSQL to confirm whether we have chosen appropriate data type mappings. Additional information can be found in the CodeGen documentation.

 


CodeGen 5.1.4 Released

By Steve Ives, Posted on July 29, 2016 at 10:42 am

We are pleased to announce that we have just released CodeGen V5.1.4. The main change in this version is an alteration to the way that CodeGen maps Synergy time fields, i.e. TM4 (HHMM) and TM6 (HHMMSS) fields, to corresponding SQL data types via the <FIELD_SQLTYPE> field loop expansion token. Previously these fields would be mapped to DECIMAL(4) and DECIMAL(6) fields, resulting in time fields being exposed as simple integer values in an underlying database. With this change it is now possible to correctly export time data to relational databases.

We also made a small change to the CodeGen installation so that the changes that it makes to the system PATH environment variable occur immediately after the installation completes, meaning that it is no longer necessary to reboot the system after installing CodeGen on a system for the first time.

This version of CodeGen is built with Synergy/DE 10.3.3a and requires a minimum Synergy runtime version of 10.1.1.


CodeGen 5.1.3 Released

By Steve Ives, Posted on June 30, 2016 at 1:11 pm

Tomorrow morning I’m heading back home to California having spent the last two weeks in the United Kingdom. The second week was totally chill time; I spent time with family and caught up with some old friends. But the first week was all about work; I spent a few days working with Richard Morris (it’s been WAY too long since that happened) and I can tell you that we worked on some pretty cool stuff. I’m not going to tell you what that is right now, but It’s something that many of you may be able to leverage in the not too distant future, and you’ll be able to read all about it in the coming weeks. For now I wanted to let you know that we found that we needed to add some new features to CodeGen to achieve what we were trying to do, so I am happy to announce that CodeGen 5.1.3 is now available for download.



CodeGen 5.1.2 Released

By Steve Ives, Posted on January 28, 2016 at 9:55 am

We have just released a CodeGen update that includes a fix for a problem that was discovered recently related to the processing of enumerated fields. If your repository includes enumerated fields and you use the field selection loop token <SELECTION_VALUE> (or the Symphony Framework custom token <SYMPHONY_SELECTION_VALUE>) then we recommend that you update to the new version and re-generate your code. As a reminder CodeGen recently moved to GitHub, you can find the new release at https://github.com/Synergex/CodeGen/releases.


CodeGen Has a New Home

By Steve Ives, Posted on December 9, 2015 at 1:45 pm

Today we are announcing that we have moved the open source CodeGen project from it’s former home on CodePlex to a new home on GitHub. We made the decision to do this for several reasons, not least of which is the fact that GitHub has effectively become the de-facto standard place for hosting open source projects. Even Microsoft, who built and operate the CodePlex site using their own Team Foundation Server source control technologies seem to have lost interest in it; in the last 18 months or so they have moved pretty much all of their own considerable number of open source projects to GitHub also! GIT also has several very nice features over and above what TFS has to offer, and also has the benefit of being very considerably faster to use. Related to the move is a new version (CodeGen 5.1.1), but the only changes in the new version are related from the move from CodePlex to GitHub; there is no new functionality in the new release over the 5.1.0 version that was released a few days ago.

If you don’t already have one we encourage you to create a GitHub account and once logged in to “watch” CodeGen. If you wish to receive notifications about new CodeGen releases you can also subscribe to the CodeGen Releases Atom feed. CodeGen is still distributed under the terms of the New BSD License. For the time being we plan to leave the CodePlex environment intact, but no new changes will be checked in there and no new releases will be published there.

Here are a few useful GitHub URLs related to our new home:

Project home https://github.com/Synergex/CodeGen
Wiki (information) https://github.com/Synergex/CodeGen/wiki
Download latest version https://github.com/Synergex/CodeGen/releases/latest
Issue tracking https://github.com/Synergex/CodeGen/issues
Releases Atom feed https://github.com/Synergex/CodeGen/releases.atom

CodeGen 5.1 Released

By Steve Ives, Posted on December 4, 2015 at 4:07 pm

Just a quick note to announce that we have today released CodeGen 5.1. This release has but one new feature, but it does allow me to solve a challenging problem that I faced while working on a customer project recently. I have dubbed this new feature conditional processing blocks. Essentially it is the ability to conditionally include (or exclude) parts of a template file based on the presence or absence of identifiers that can be declared on the command line. It allows you to achieve the same kind of results that you would when using .DEFINE, .IFDEF and .IFNDEF in DBL source code, but within template files. For example a developer could include code like this in a template file:

    open(channel=0,u:i,”<FILE_NAME>”)
    <IF DEFINED_ATTACH_IO_HOOKS>
    new <StructureName>Hooks(channel)
    </IF>

The developer would then have the ability to choose whether to include or exclude the code that assigns the I/O hooks object to the channel that was opened at the time that they generate the code. By default the I/O hooks code would not be included; if it was needed the developer would define the ATTACH_IO_HOOKS identifier as they generate the code. They would do this by using a new –define command line option:

    codegen –s EMPLOYEE –t FILE_IO_CLASS –r –define ATTACH_IO_HOOKS

This may seem like a very simple change, and it is, but my mind is now racing thinking about all of the new possibilities it opens up.


CodeGen 5.0.5 Released

By Steve Ives, Posted on August 28, 2015 at 12:59 pm

Just a quick note to let all of you CodeGen users out there that a new version (CodeGen 5.0.5) has just been released. You can get more information about the changes and download the release from https://codegen.codeplex.com/releases.

If you would like to receive email or RSS notifications when new CodeGen versions are released then there are links on the above mentioned page to allow you to set that up, and we encourage you to do so.


CodeGen Training Videos

By Steve Ives, Posted on April 28, 2014 at 7:36 pm

I finally got around to something that I have been meaning to do for a while, creating some short training videos for CodeGen. Just five videos right now, but I have a growing list of subjects for future videos.

You can view the videos on the Synergex Channel on YouTube.

Please subscribe to the YouTube channel to receive notifications when new videos are added.


Unit Testing with Synergy .NET

By Steve Ives, Posted on January 14, 2013 at 11:02 pm

One of the “sexy” buzz words, or more accurately “buzz phrases” that is being bandied around with increased frequency is “unit testing”. Put simply unit testing is the ability to implement specific tests of small “units” of an application (often down at the individual method level) and then automate those tests in a predictably repeatable way. The theory goes that if you are able to automate the testing of all of the individual building blocks of your application, ensuring that each of those components behaves as expected under various circumstances, testing what happens when you use those components as expected, and also when you use them in ways that they are not supposed to be used, then you stand a much better change of the application as a whole behaving as expected.

There are several popular unit testing frameworks available and in common use today, many of which integrate directly with common development tools such as Microsoft Visual Studio. In fact some versions of Visual Studio have an excellent unit testing framework build in; it’s called the Microsoft Unit Test Framework for Managed Code and it is included in the Visual Studio Premium and Ultimate editions. I am delighted to be able to tell you that in Synergy .NET version 10.1 we have added support for unit testing Synergy applications with that framework.

I’ve always been of the opinion that unit testing is a good idea, but it was never really something that I had ever set out to actually do. But that all changed in December, when I found that I had a few spare days on my hands. I decided to give it a try.

As many of you know I develop the CodeGen tool that is used by my team, as well as by an increasing number of customers. I decided to set about writing some unit tests for some areas of the code generator.

I was surprised by how easy it was to do, and by how quickly I was able to start to see some tangible results from the relatively minimal effort; I probably spent around two days developing around 700 individual unit tests for various parts of the CodeGen environment.

Now bear in mind that when I started this effort I wasn’t aware of any bugs. I wasn’t naive enough to think that my “baby” was bug free, but I was pretty sure there weren’t many bugs in the code, I pretty much thought that everything was “hunky dory”. Boy was I in for a surprise!

By developing these SIMPLE tests … call this routine, pass these parameters, expect to get this result type of stuff … I was able to identify (and fix) over 20 bugs! Now to be fair most of these bugs were in pretty remote areas of the code, in places that perhaps rarely get executed. After all there are lots of people using CodeGen every day … but a bug is a bug … the app would have fallen over for someone, somewhere, sometime, eventually. We all have those kind of bugs … right?

Anyway, suffice it to say that I’m now a unit testing convert. So much so in fact that I think that the next time I get to develop a new application I’m pretty sure that the first code that I’ll write after the specs are agreed will be the unit tests … BEFORE the actual application code is written!

Unit testing is a pretty big subject, and I’m really just scratching the surface at this point, so I’m not going to go into more detail just yet. So for now I’m just throwing this information out there as a little “teaser” … I’ll be talking more about unit testing with Synergy .NET at the DevPartner conferences a little later in the year, and I’ll certainly write some more in-depth articles on the subject for the BLOG also.


Symphony Framework and CodeGen Helping Customers Migrate to a WPF UI

By Steve Ives, Posted on August 1, 2012 at 4:20 pm

Richard Morris and I have just returned from a seven-day consulting engagement with a customer, and I wanted to share with you some information about our achievements during the visit. The customer we visited with is one of our larger ISV’s and has an extensive Synergy application, much of which is implemented using the Synergy/DE UI Toolkit. As with many applications, life started out on cell-based systems many years ago, but for many years now it has been deployed exclusively on Windows systems.

SymphonyLogoThe customer in question had listened to us talking about Symphony Framework and CodeGen at the Chicago DevPartner conference, and was interested in how they might be able to leverage them to accelerate the process of updating the look and feel of their applications by replacing their existing UI Toolkit user interface with a Windows Presentation Foundation (WPF) user interface. Needless to say we were eager to help, because we believe we have a great story to tell, and some great tools to share!

Most in the industry would agree that WPF represents the current “state of the art” when it comes to implementing user interfaces for Windows Desktop applications. We have had our eyes on WPF for some time now, and have been learning about it’s capabilities. We have also been encouraging customers to consider WPF as a great way of updating the UI of their existing applications, or implementing the UI of new applications. And thanks to new features in Synergy/DE 9.3 and 9.5 there are a couple of great ways of doing just that.

For existing applications the Synergy/DE .NET Assembly API can be used to embed WPF directly into existing applications. Of course one of the main benefits of doing so is that the application can be enhanced screen-by-screen, without the need for extensive re-writes and long development cycles. Of course for new development Synergy .NET can be used to build all-new applications with a WPF user interface. There is also a realistic migration path between the two; you can chose to start off by enhancing screens in an existing application via the .NET Assembly API today, and then ultimately migrate the entire application to a native Synergy .NET solution. All very “doable”.

Before I get into the specifics of our tools and what was achieved, there is one more thing that I should mention. Just as most industry pundits would agree that WPF is the way to go for Windows Desktop applications, most would also tell you that there is a specific WAY that WPF applications should be implemented; it’s called the “Model-View-ViewModel Design Pattern”, which is often abbreviated as MVVM.

A design pattern describes a methodology for implementing a software solution to a certain problem. The MVVM design pattern sets out a way of designing software such that there are clear lines of demarcation between code that deals with different parts of an application. Specifically it prescribes how the “Model” (code which implements an applications data definitions and business logic) should be separated from the “View” (code which implements the applications user interface), and how these two entities should be joined by the “ViewModel”. We’ve talked quite extensively about MVVM in the past, and there are lots of great resources available on line, so I don’t intend to go into more detail here. Suffice it to say that adhering to the MVVM design pattern is strongly recommended when implementing WPF applications.

I mentioned earlier that we have been focusing on WPF for some time now, and also on MVVM. But as well as just learning about the technologies and patterns, Richard Morris has been “beavering away” at his home office in England pondering the question “how can we help our customers to easily use WPF and MVVM in the context of their existing Synergy applications?”. Once he’d finished pondering the question, he then started coding the answer … and the Symphony Framework was born.

So just what is the Symphony Framework and how can it help you? Well in a nutshell, Symphony Framework is an MVVM Framework (library) which can be leveraged by Synergy developers to significantly simplify the process of implementing WPF user interfaces in their Synergy applications, while at the same time adhering to the best practices prescribed by the MVVM design pattern. Symphony Framework can be used to incrementally add WPF UI to existing applications in conjunction with the .NET Assembly API, and it can be used to implement all-new Synergy .NET applications with a WPF UI.

Some areas of Symphony Framework are designed to specifically address the somewhat unique challenges associated with migrating UI Toolkit applications, but the framework is in no way limited to working only with UI Toolkit applications. To cut a long story short, if you have an existing Synergy application and want to “spiff it up” with a fabulous new WPF UI, then Symphony Framework might just become your new best friend!

I’m not going to go into a huge amount of detail about HOW this all takes place, but I do want to briefly describe some of the common steps. For the purpose of this illustration I’ll ask you to imagine an existing UI Toolkit application (but remember, it doesn’t have to be Toolkit), and imagine that I want to do a gradual screen-by screen migration to a WPF UI, initially driven by the existing application (via the .NET assembly API). What might the steps be? Well, for each screen (or window) we might:

  • Create a “Model” class that describes and exposes the underlying data to be worked with. Model classes inherit a lot of functionality from base classes in the Symphony Framework.
  • Create a “View” using WPF.
  • Create a “ViewModel” that exposes the information in the model to the view, and provides the functionality needed to service the requirements of the view. ViewModel classes also inherit a lot of functionality (in some cases all of the required functionality) from base classes in the Symphony framework.

The code for all of the steps described above would be implemented in Synergy .NET and would be compiled into a .NET assembly.

  • Use the .NET assembly APIs “GENNET” tool to create Traditional Synergy “wrapper” classes that allow these various components to be accessed and manipulated from the existing Traditional Synergy application.
  • Create a “Manager” class (we’re still trying to figure out what to call this bit!) which contains the bulk of the code required to instantiate and drive the underlying .NET code.
  • Modify the existing application to present the new WPF UI instead of the existing UI, primarily by accessing functionality exposed by the “Manager” class.

You might be tempted to see this last bullet point and think “there is is, modify our existing code, that’s the hard and time consuming part”! But don’t let this thought put you off, believe it or not the changes that typically need to be made to the existing code are relatively small and painless. This is due in no small part to the things that the Symphony Framework is doing for you!

During our visit with our customer we initially worked on what it would take to replace existing “lookup” routines with new WPF implementations. In a UI Toolkit application a lookup routine is often accessed via a “drill method” associated with an input field, and often uses a combination of input processing to allow the user to define search criteria, and list processing to present matching results. When the user picks an item the associated value is returned into the input field. We managed to get this process down to a fine art. and this is where CodeGen comes in.

CodeGen1We were able to create CodeGen templates which allowed us to generate most of the code that was required to “switch out” a UI Toolkit lookup for a WPF lookup. We were able to code generate 100% of the Model class, 100% of the View class, 100% of the ViewModel class, and 100% of the “Manager” class. All that remained was to modify the existing application to utilize the new code instead of the existing UI Toolkit UI. Figuring out how to do the first lookup probably took in the order of half a day, but with the process and CodeGen templates in place, the next four lookups probably took around 20 minutes each to implement. We left it at that, because we were confident that we had the process down at that point.

Then we moved on to other areas, attacking a “maintenance” type program. The process is actually remarkably similar, and actually not that much more complex, again because much of the base functionality required is inherited from the Symphony Framework. By the end of our engagement we pretty much had that process down also, and again much of the required new code was being code generated, leaving only relatively minor changes to the existing application to be made.

Of course not all aspects of an application are as simple to deal with as the scenarios that I just described, some parts of an application and its UI get pretty complex, and it isn’t always possible to code generate all of the required components, and it isn’t always possible for the Symphony Framework to provide all of the required functionality in the form of base classes. Programmers still have a role to play, and thank goodness for that! But I do believe that the tools that Richard and I have developed can play a significant role in projects of this type, and it’s not just theory, we just proved it!

Actually that’s probably not a totally fair statement for me to make, as there are several other customers who have already used the Symphony Framework with great effect. Just as there are many customers who already use CodeGen to generate many different types of code to address various application needs. But Richard and I don’t often get to work together on a project, and this is perhaps the first time that we have really tried to use both of these tools together and push them HARD to see what could be achieved. And I for one am confident that everyone involved, including our customer of course, was pretty impressed with the results.

By the way, if your goal is to build an all-new WPF application directly in Synergy .NET, while retaining and re-using large portions of your existing code, then the steps aren’t that different to those described above. The Models, Views, ViewModels and “Manager” classes would be essentially the same, but would be driven by a Synergy .NET WPF application rather than by a DBR application via the .NET Assembly API. We actually proved this recently while preparing a proof of concept demo for another customer. Having been provided with the code for a small sample application, and some sample data, we migrated the UI of the application to WPF using the steps described above. Once the application was working with a new UI, and armed with the classes that we had just created, we were able to re-purpose those classes without change in a 100% Synergy .NET WPF application. In all the process took about four hours … but probably could have been completed faster had we not been sat at a bar at the time! This really is pretty cool stuff!

Before finish I do want to stress one more time that the Symphony Framework and CodeGen tools are not just about UI Toolkit applications on Windows. Symphony Framework helps you migrate to an ultra-modern WPF UI on Windows, but the starting point could easily be an application that runs on a cell-based platform today. And CodeGen can be and is being used on all systems supported by Synergy.


Release Notifications for CodeGen and Symphony Framework

By Steve Ives, Posted on July 31, 2012 at 5:19 pm

At the DevPartner conference I told people that in order to receive notifications for new releases of the open source CodeGen and Symphony Framework projects they should “Follow” the projects on CodePlex.

It turns out that “following” a project doesn’t send release notifications. If you want to get release notifications then you must go to the “Downloads” page for each project and subscribe for notifications. If you are interested in either of these two projects then I would recommend that you do just that, as we’ve done some great enhancements to both recently, and there are more great things still in the pipeline.

The downloads page for CodeGen is at http://codegen.codeplex.com/releases and the downloads page for Symphony Framework is at http://symphonyframework.codeplex.com/releases.


CodeGen 4.1 Released

By Steve Ives, Posted on June 7, 2012 at 12:48 am

Recently I announced that our code generator, CodeGen, had been published on CodePlex for everyone to use. Today I am delighted to announce that we have released a new version of CodeGen which includes some significant new features.

It is now possible to generate code which is based on information drawn from multiple repository structures, which makes it possible to generate many more types of routines and classes than ever before.

Also we have added the ability to launch code generation based on a repository file definition. CodeGen will make any structures that are assigned to the file available to the template when generating code.

We’re now starting planning for the next release. CodeGen can already be used to generate code for Synergy Language, C#, Visual Basic and Objective-C, and one of the features we’ll be adding in the next release is data type mappings and new field loop tokens for the Java language.

For more information about CodeGen refer to the CodeGen site on CodePlex, which you will find at http://codegen.codeplex.com.


CodeGen Goes Open Source

By Steve Ives, Posted on May 22, 2012 at 9:45 am

For several years now I have been developing a tool called CodeGen. As you may have already guessed from the name, it’s a code generator! What’s a code generator? It’s a tool that generates code … sounds useful, right?

Well it is useful, in many different situations. Not all situations of course. If a code generator could generate ANY piece of source code that you might need then we wouldn’t need programmers any more … so why would a programmer write such a tool?

OK I jest a little. Believe me, if it were possible to write such a tool then I would have done it, and I’d have made a lot of money from it, and I probably wouldn’t be sitting here writing this BLOG right now 🙂 No, of course it’s not possible to write a tool that can generate ANY piece of source code, but it absolutely is possible to create a tool that can generate useful code to address a wide variety of different requirements, and that’s what CodeGen does.

So just what is CodeGen? Well, I generally describe it as a “template-driven” code generator. What that means is that you start with a template file that defines the general “rules” for the code that is to be created, and you combine the information from that template file with some meta-data in order to produce the final code. So now the question is where does the meta-data come from? Well, when using CodeGen, in most cases it comes from a Synergy repository.

A repository database is an extremely rich source of meta-data relating to the data structures that are used within your applications. The applications that we write totally revolve around data, they create data, update data, and analyze and present data. So having a repository which completely describes not only the data structures that your application uses, but also a huge amount of additional information about HOW that data is represented and to processed, and armed with an API (ddlib) which allows programmatic access to that meta-data, a programmer can create software that “does things” based on that information. That’s what CodeGen does.

By the way, don’t fret it if you don’t already use Repository … that’s easy to address.

I have no intention of “rambling on” about what CodeGen is and how it works, because that information is all available elsewhere. CodeGen has been in use for several years, I use it extensively, and I have used it to deliver real value to several customers also. In fact in the past, that was the model. CodeGen was a tool developed by Synergex Professional Services Group, and it was available for us to use during consulting engagements. If we used it during such an engagement then that customer got to continue to use the tool, and many have done so.

The real point of writing this post is to announce, with great delight, “that times are a changing”. We’ve decided to take a different tack, and make CodeGen available to a wider audience; a MUCH wider audience. I am delighted to announce that CodeGen is now an Open Source product, and is published for the world to download and use. The project is hosted on CodePlex (Microsoft’s Open Source hosting platform) and you can view the CodeGen project home page at http://codegen.codeplex.com.

So just what does this mean? Well, it means that CodeGen is now available for you to download and use, and I hope that lots of you do just that. CodeGen is now primarily developed with Synergy .NET in Visual Studio, and if you want to use it you have two choices:

  1. Download the pre-built distribution (a Windows Installer setup program).
  2. Download the source code package and build it yourself.

The binary distribution is built with the latest version of Synergy.NET (9.5.3b), so you’ll need that version of Synergy to use it. If you’re working with an older version of Synergy then you’ll need to build CodeGen from source code, but you’ll still need a pretty recent version of Synergy/DE.

Even though the main development environment for CodeGen is now Synergy .NET, it wasn’t always that way. CodeGen started out life as a regular “Traditional Synergy” application, and it still works just fine that way. What that means is that CodeGen is equally at home under Synergy .NET or Traditional Synergy on Windows, Unix, Linux or OpenVMS, and the source code download includes scripts to build CodeGen on all of these platforms.

If you are currently attending the Synergex DevPartner Conference in Chicago, IL then you’re going to hear more about CodeGen during the conference today, and on Tuesday afternoon there will be a hands-on tutorial available to help you get real experience working with it. And if you’re attending the conference in York, England in June then don’t fret, you’ll get the same opportunity. But if you’re not attending either conference (it’s not too late to sign up for York) then you’re definitely missing out on some great information about CodeGen, and a BUNCH of other cool stuff!

But just because you’re not attending the conference doesn’t mean that you can’t use CodeGen. Head on over to http://codegen.codeplex.com to get started right now. And please, even if you don’t use CodeGen right now, at least “follow” the CodePlex project so that you’ll be kept up to date with news about the product.

By the way, to my best of my knowledge this is the first time that a “DIBOL” (Synergy) application has been published as an open source project, and I’m pretty stoked about that. BUT … there’s more! There’s another open source Synergy project about to “hit the streets” … and it utilizes CodeGen … but I’ll leave it up to my friend and colleague Richard Morris to tell you all about that!


Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Tag Cloud Archives