…you’d get SparkleShare. It automatically synchronizes directories to Git repositories, whether you host them locally or on some service like GitHub.
Now, don’t get me wrong: this isn’t how you want to do version control for your software, where meaningful commits are important. This is more for “data” or “asset” files – I’ve seen it used for project artwork/icons, for instance. It can also be handy for managing an essentially static web site built with a tool like Jekyll. For those use cases, it can be a great tool, particularly for non-programmers.
I’ve recorded a screencast showing how to install (even as a non-admin) the app on Windows, set it up to link with your GitHub account (they handle ssh keys transparently in the background), and add your first repo. Enjoy!
[EDIT: Sorry, Screenr has gone away along with this screencast.]
[EDIT TO ADD]: Ubuntu includes SparkleShare in its repos, but it’s an outdated version (in all releases). A useful PPA to add would be this: https://launchpad.net/~rebuntu16/+archive/sparkleshare+unofficial Note that SparkleShare requires Git, and the newer the version of Git, the better your life generally is, so make sure you have the Git update PPA also enabled: https://launchpad.net/~git-core/+archive/ppa . Something like this would add them for you:
sudo add-apt-repository ppa:rebuntu16/sparkleshare+unofficial
sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
(optionally sudo apt-get dist-upgrade or other method of upgrading your git packages)
sudo apt-get install sparkleshare
[Update March 26: Re-uploaded the tool, I had scaling backwards. Oops!]
File format management seems to be a perpetual problem in CAD. For folks looking to convert a SolidWorks assembly to use in OpenSceneGraph and maintain the position and orientation of the parts relative to each other, we’ve figured out what seems to be the ideal workflow, at least for now. A nice feature: it doesn’t require any commercial, proprietary software beyond SolidWorks itself. I’ve documented the process in two screencasts on my Screenr account, which I’ve embedded below.
Download the Windows tool used in the screencast here: osgconv-20130319-solidworks-stl
First step: Export files from SolidWorks to STL.
Second step: Convert STL files to OSG files in bulk.
I’ve been looking at some web java-based screencasting apps, namely screenr and Screencast-o-matic, which look suspiciously similar. I wanted to record a voiceover along with a screencast, but couldn’t get it to work – on a Windows 7 x64 machine with 64-bit Java 7 installed (as well as I think 32-bit Java 7).
Long story short, the only way I could get either tool to recognize the fact I had any sound recording devices at all was to run it in Internet Explorer 64-bit (heaven forbid!). Hopefully this helps someone – if you know why this is, I’d be curious to find out.
I recorded a brief screencast for the benefit of my classmates who would like to work in the X-Code environment on the Mac (for editing, building, and debugging) for their ME/CprE 557 assignments.
You can go to the video directly by clicking: X-Code and OpenGL Tutorial Screencast.
Note: The replacement include statements I list in the screencast are actually a bit more than necessary – you can use these shorter ones instead (be careful: those are two underscores on each side of the word APPLE):
Where you see:
and where you see this (in later assignments only):
Why? GLUT (glut.h) includes gl.h, and GLUI (glui.h) includes glut.h, thus you only need the “highest level” of abstraction and utility around the core OpenGL explicitly included.
If you get an error regarding tchar.h when compiling the sample apps, that’s just because TCHAR is a Windows-only macro that turns into the correct kind of char for a particular build. You’ll just want to use regular “char” and “int main” when making your own app, but to avoid modifying the sample apps too much, you can just download this tchar.h file and add it to the X-Code project. (It just makes the substitution for you at compile time.)
Remember: The professor will still be using the Makefile (example provided in 557_Support_Files.zip) to re-compile your application, so make sure you update the Makefile and test it before submitting. You’ll want to submit your cpp and h files, your Makefile, and a binary – best to include the one made by the Makefile, but if you want to find your X-Code one (for testing or another purpose) it’s in the build directory inside your project directory, in the Debug or Release folder (depending on your build configuration chosen in the main X-Code project view).
Feel free to click on this post title (to view it on its own) and bookmark that page for your own use.