coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

·         It has been an extreme amount of time since I've done a status update-we've been working hard here, honest! Under a stack of what seems like a million little things, blogging has taken a backseat to development in recent months, but I'm hoping to correct that (and have some others do some blog posts too!)

As you can see, we're on a new site; this is powered by Orchard<http://orchardproject.net/>, an open source CMS for Windows. I chose this, primarily because it's built to run on Azure<http://www.microsoft.com/windowsazure/> as well as Windows Server, and the kind folks at Microsoft have given me an Azure account with plenty of resources. I also spun up a Screwturn<http://screwturn.eu/> Wiki for documentation (it's what the Orchard guys use for their site, so I followed suit).

The new site is a tad bare right now, but hopefully we'll get this all put together over the next couple of weeks.

A new code repository

As I mentioned on my blog last week<http://fearthecowboy.com/2011/04/26/weve-moved-coapp-code-hosting-to-github/>, we also moved our code repository over to github:
§  While I liked a lot of the things about Launchpad, the website is feeling slower and slower some days, and Bazaar, while offering the features that I like, isn't getting the attention (and developer resources) that git is. Combined with the fantastic innovation happening at Github, it's undeniably the go-to place for open source development these days.
§  And, having done some recent tests with git on Windows, it's clear that it's stable and feature rich enough for all my purposes.

Along with that I also talk about how to checkout the code and compile it up. Yes, it's still an iceberg (most of the code isn't about what you see) but beneath that surface there is a huge amount of functionality lurking.

Current Status

The last six months have had a flurry of code development done, including essentially the entire CoApp engine-originally we were hoping that the volunteer work by the group at the University of Syracuse would produce a functional prototype, it turned out to be too-aggressive of a goal. Consequently, the entire engine was written in three months, and diverted my attention away from other things (this site being one of them)

Where we at:
CoApp Core:
o    CoApp toolkit - all of CoApp's shared code ends up in the toolkit project. A cornucopia of functionality, it provides a tremendous amount of simple, reusable functionality that is shared across all projects.
o    CoApp Engine - we have a managed version of the engine with the basic v1 functionality complete, I'd say that it's in a solid beta stage at this point.
o
o    CoApp Command Line Client - the command line client works pretty good, if a tad verbose on the command line. It's pretty optimized for the happy-path at this point, but still a pretty good beta.
Publisher Tools:
o    mkPackage - the first tool to create packages for CoApp has been working, but it turned out it took an awful lot of effort to build a package, so we've depricated that, and gone back to the drawing board. The result, is Autopackage-a tool designed to do what we really wanted, which is creating packages without messy XML, no need to understand MSI or WiX, or even code signing.
o    Autopackage-is designed to eliminate 100% of the understanding and guesswork in creating packages for consumption. It's already functional and able to produce packages, and is nearing the 'alpha' stage. Eric has done an amazing amount of work in a short time to produce something that is going to get a lot of attention.
o
simplesigner - even simple code signing operations are a hassle in Windows, and when you add .NET strong-naming into the mix, it's all a little difficult to get a hold of, so I wrote the simplesigner tool.. It does exactly what it says, makes digital signing software on Windows simple. For .NET executable binaries, it both signs and strong-names the result, and eliminates the guesswork and frustration entirely.
o
Developer Tools:
o    Scan-Trevor knocked out the first beta of this tool way back in October, It does exactly as I'd hoped, a very useful scan of a source tree, and brings back a very large amount of useful data. On top of it's use as part of mkSpec, it's also quite handy on it's own to get an idea of what a project uses, and how it all fits together. Solid 1.0 material.
o
Trace-The ultimate evolution of my original 32 bit trace utility, Rafael and I have put an insane amount of work into this tool. Trace can watch a program, and all of its child processes and record every single file access (and how it was accessed), and record the environment, and command lines for every process. It works for nearly every type of application we've thrown at it: 32bit, 64bit, .NET, cygwin, native... The data it gets back is extremely valuable-we use it primarily to feed into the mkSpec tool to produce project files, but it has a lot of use on it's own. It even captures some data that you can't get from Sysinternals' ProcMon. We're pretty much 1.0 gold here.

mkSpec-The tool that generates a 'compiler-independent' project file from scan and trace data. It's getting really close to beta stage-I just need to leverage the latest trace info and we should be on our way.

mkProject - the secret sauce of the entire CoApp project. mkProject takes project info from mkSpec and produces Visual Studio project files that are consistent, clean and support easy use of advanced features like PGO optimization, etc. Still a work in progress-probably a few weeks away from a beta.
o    testpackagemaker - development of the package manager requires a lot of testing examples, and this tool simplifies the generation of native and .NET executables and libraries that support side-by-side so we can build packages for testing. Solid 1.0 stuff here.
o
pTk - a recent addition to the CoApp developer tool lineup, pTk (aka the porting Toolkit) is a build automation tool (no, not like make or msbuild). pTk provides a method for package maintainers to express 'how-to-build' a given project so that the process can be automated by other tools without understanding anything about the build whatsoever (this will let us automate the trace/mkSpec/mkProject process *a lot*.) Rather than having the package maintainer/developer express a build process in its terms, it simply is a way of letting the developer write down the commands to build a given project (as a command, or batch script, or whatever) and provides an automatable wrapper for that. This is definitely release candidate material.
Productivity Tools:
o    quicktool - During development, it's always so useful to share code, screenshots etc. when working remotely (either live, via Skype, Lync or IRC) or even via Twitter or email. quicktool provides a system-wide hot-key to uploading images, formatted source snippets, and shortening URLs without having to bring up a separate tool or browser to do so. Faster and more convenient than clumsy websites like pastebin, it allows developers to easily share information at a single keypress.
o

That's about it for today... over the next few days I'll be posting some tutorials (ie, how to shallow fork a Project for CoApp) and some more information on how you can get involved if you're inclined.



[Description: Description: Description: fearthecowboy]<http://fearthecowboy.com/>

Garrett Serack | Microsoft Open Source Software Developer | Microsoft Corporation
Office:(425)706-7939                                       email/messenger: garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>
blog: http://fearthecowboy.com<http://fearthecowboy.com/>                                      twitter: @fearthecowboy<http://twitter.com/fearthecowboy>

I don't make the software you use; I make the software you use better on Windows.