Helix SDK Q&A - Recent questions

How to build Helix on a Mac

Thu, 12 Nov 2015 21:00:28 +0000

Outline of the steps required to get Helix to build on a Mac.

Good links to Git references

Thu, 26 Sep 2013 18:55:04 +0000

I don't have a quick place to put these right now, and I don't want to loose them and then try to find them again later. So I'm putting them here. If you have others, feel free to add responses with your favorites.

Git Version Control Linkfest: http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide?lq=1

Git Cheatsheet - Really Cool: http://www.ndpsoftware.com/git-cheatsheet.html

Git Branching Model: http://nvie.com/posts/a-successful-git-branching-model/

Templating Engines

Wed, 11 Sep 2013 19:54:53 +0000

A big part of the power of Helix is that we try to generate as much of the common code for you as possible. You define the structure of what you want, and we'll generate the code to implement that structure in your desired language.

At the heart of this is our code generation engine. This started out as a Java program, which morphed into a C++ program, and is now under surgery to become something new.

When writing code that writes code - at the beginning - it's easy to simply inline the bits of code that will be generated as strings in the master code generation program. That's what we have now. That's how it was in Java, and how it got morphed into C++ as well.

As we go forward, though, this becomes harder and harder to maintain. We need to generate more code. We need to pay attention to more situations, and we need to be more and more sophisticated. I can see where we need to go, but, for the time being I just don't know exactly what it's going to look like.

So, I've opted for small steps and to iterate my way through the problem.

First step is to extract as much of the hard-coded inline strings from the code generation engine and put them into separate template files. This is an on-going effort, but it is already making the code generation engine much cleaner and clearer to understand. It also means that I don't necessarily have to re-compile the code generation engine when I need to tweak the output. As long as what I need to tweak is in one of the template files, I just update it and go. This is already making life much easier.

I hesitate to use one of the more powerful templating solutions at this point, because I worry that I'm just trading one set of problems for another. I like it when the templates are extremely clean and have very little xml or other cruft in them. I recognize, though, that the logic of the if/else/loop/etc. code generation engine has to go somewhere. It's either going to be embedded in the templates themselves - and evaluated by the template engine, or it will stay in our existing code-generator and get applied to more simple template files.

I don't have the right answer yet. I only know I have to do something to make this more maintainable. Iteration is the key. I'll keep doing small things to make it better, and I'll keep looking at the templating engines out there to see if I can find the right balance.

Iteration is important

Wed, 11 Sep 2013 19:34:13 +0000

Sometimes I look at a piece of code or a design or a problem that I want to solve and I can see the ultimate goal for how I want to approach it. I can see it very clearly. When this happens, I go straight to the end goal and do it the way that I can see it in my mind. When this happens it's great and I can get a tremendous amount accomplished in a very short time. It's great when it happens.

Unfortunately, it doesn't always happen that way.

Sometimes I look at a piece of code or a design or a problem and I know that it can be so much better. I know that there is a smooth and elegant way to approach it. I can feel it in my bones. I just can't see it yet.

The problem with these times when I know there is an elegant solution but I can't see it, is that it's like writers block for me. It will make me sit and stew and do nothing, because I can't quite formulate exactly what I want to do.

I've found that the best way to get past this writers block is to just force myself to do something. Anything. Just start with small changes, or pieces of code and gradually iterate through changing them and getting them closer and closer to where I need to end up.

It's like that scene in Finding Forrester where Sean Connery tells Rob Brown to just start typing. He starts with a paragraph from an existing paper, and then it starts to flow from himself.

Start with something. Even just a simple loop that has nothing in it. Get it to compile. Add more to it. Compile it, run it, extend it. It starts to flow. Then you can get it to do what you need it to do.

Iterate. Don't be afraid to start small and grow it into something bigger with many, many iterations.

Everything must be working ... the spammers have found us!

Tue, 06 Aug 2013 19:12:51 +0000

It's like a rite of passage or the mark of having arrived. When you set up a free-form site like this one, you hope that people will find you organically on the web. One of the best ways to know for certain that links are working, and that the site is visible is to wait for the spammers to find you. If even the spammers can't find you, well then something is really not working and you need to go back to your configuration and figure it out.

I was getting a little worried, because Helix Q&A has been up for a week or so at this point, and I hadn't seen anything yet. But today brought absolute confirmation that everything is up and running properly, and that we are visible to the world: the spammers have arrived

The site's volume is low enough at this point that I'm still going to keep it pretty open. I'll handle keeping things clean manually until it gets to the point where I'm overwhelmed. When that happens, I'll tweak the settings to start locking things down a bit more.

Cheers!

Website Source and SDK Source separated

Fri, 26 Jul 2013 20:47:32 +0000

I've updated the source tree to pull the website contents out of the main SDK source. It's not necessary as part of the SDK and this will help shrink download sizes for anyone pulling down the full SDK source rather than picking up one of the pre-built SDK packages.

Speaking of pre-built SDK packages - no, I don't have those ready yet. Here's the plan for them:

Inside the source tree there's a series of components that are used to do the "SDK" job, and a series of components that are used to become the application that the SDK will provision and create based on your project definition. Granted, there's a lot of overlap between these - as the SDK is really just another project built with the same components. Dogfooding

So when we build the SDK - we'll package up this application, and make it available on the following platforms:

Win32 - Native Service
Win64 - Native Service
Linux32 - RPM or DEB package, or simple .tar.gz file.
Linux64 - RPM or DEB package, or simple .tar.gz file.

The SDK itself is built using the C++ version of the server in stand-alone mode, so that there will be no external dependencies. You won't have to have apache up and running somewhere to get this going. Just drop it down and run with it.

The SDK application is where you will "provision" your new projects. By "provision" we mean going through the simple process of defining the application you would like to build. Here are the things that we will ask you during this process:

What is your project name?
What is your project namespace prefix?
Would you like to use Java, C++, or C# as your server language - which also constrains deployment options.
- For Java, would you like to deploy as a WAR file to an application Server or as a stand-alone Java server.
- For C++ would you like to deploy as an Apache module or as a stand-alone native server.
- For C# would you like to deploy as an IIS Handler or as a stand-alone .Net server.
Where would you like your project source files to go.
What port would you like your server to listen on - default 7294 (Helix SDK uses 7293)

With this information the SDK application will take the appropriate source code templates, customize them, and create your project directory in the right place with the right settings. The SDK also knows how to get all of the 3rd party components downloaded and installed on your development machine. These could include:

Current Qooxdoo Framework
Current Python runtime (required by Qooxdoo build toolchain)
Any development libraries (libxml2, libzlib, libopenssl, etc.) and headers that may be necessary.

Finally, the SDK will create the appropriate project files so that you can work with your new project. For Java projects, the SDK will create Eclipse .classpath and .project files. For C++ it will create makefiles and a Visual Studio solution setup. For C# it will create a Visual Studio solution setup.

Once all of this setup is in place, the SDK will run the initial compile of your project to get you up and running. You will actually use your project to help define itself. All of the data objects, screen layouts, etc. you will define by using your project's web GUI. So it's important that the SDK get an initial compile of your project up and running so that you'll be able to work with it.

Beyond that it's up to you to define all of the features and functionality in your project. Helix provides the infrastructure, you make it a great application

Steven M. Cherry

Q&A EMail is configured and working

Wed, 24 Jul 2013 02:11:19 +0000

I was re-reading some of my favorite articles today, and this one: http://www.ericsink.com/bos/Transparency.html reminded me that it's ok to talk about the little things that are going on and be open about the nuts and bolts behind the scenes.

Well, in that thought, e-mail is working with the Q&A system today. It's a small step, but due to the fact that I have a full-time position small steps are often all that are accomplished in any given day.

The nice thing is that this will help me to be more responsive to the Q&A system, as I won't have to check it directly to see if something has been posted. E-Mail notifications can be annoying, but they can also be helpful when done right.

Enjoy!

When is a Blog a Question and Vice Versa

Tue, 23 Jul 2013 01:43:13 +0000

On StackOverflow.com they are very picky about the types of questions asked, and the types of conversations that are allowed. One of the reasons that Discourse.com was created was because they decided that a Q&A site is just not quite the same thing as a discussion forum. They'd probably (and likely have) say the same thing about a Q&A site and a blog site.

Well, not to say that they are wrong, but acknowledging that various opinons may be had - and in the interest of expediancy and re-use, we are going to be using this Q&A forum as the host for our blog topics as well. You'll be able to find them all under the blog-post tag.

As we get our feet under ourselves, this may change - and then again it may not. I like the idea of all of the conversations being in one place - regardless of whether they are truly Question and Answer exchanges.

Welcome to Helix SDK and Helix Q&A - Give us a bit, we're getting things up and running

Sat, 20 Jul 2013 01:57:06 +0000

We're an open source project, so sometimes things move fast, and sometimes things move pretty slowly.

Give us a bit of time as we're getting the source code in place, and getting everything organized.

As you can see from the main site, there's still a lot of Hericus in here. We'll get that sorted soon

Thanks for your patience,

Steven M. Cherry

smc@hericus.com