While getting my old Lego Mindstorms (an RCX 2.0 setup) set up for my little brother to play with, I learned some thigns about using it with newer versions of Windows (Windows 7 in my case). I found out here that there is a patch needed for the USB IR tower, which resolves the problem of the system locking up when the tower is plugged in. You can download it here: http://cache.lego.com/downloads/education/tower164.zip.
After installing this, things will run fine, unless you decide to use the official program and launch it more than once. At which point you will see a message like "A critical error has occurred. You may be running out of memory, or you may need
to reinstall Robotics Invention System 2.0." The solution to this is a bit messy. There is a file left behind here
Vista/Win7: C:\Users\<user>\AppData\Local\Temp\Ris 2.0.mov.#res
XP: C:\Documents and
Settings\<user>\Application Data\Temp\Ris 2.0.mov.#res
This file must be deleted each time before the program is launched. What I did was create a batch script to do this, and a Visual Basic script to launch the batch script (so it could happen without launching a command prompt window).
You'll find both scripts here: https://gist.github.com/1531705
I recommend replacing all shortcuts to theLaunchRis2.exe with a shortcut to the Visual Basic script. Note that the VB script assumes you will put put the batch script in %PROGRAMFILES(X86)%\LEGO MINDSTORMS\launchRis.bat (or %PROGRAMFILES%\LEGO MINDSTORMS\launchRis.bat on a 32 bit system), but you can easily edit the script to change the location.
Of course, this second problem is irrelevant if you decide to write the programs youself (I preferred this over the graphical tool Lego provided). There are several languages available.
Let me know if you have suggestions for improvement or run into any issues.
Wednesday, December 28, 2011
Thursday, September 1, 2011
A userscript for Viewvc
I've posted a userscript I've written as a workaround for a request for ViewVC that hasn't been done yet (despite the fact a patch has already been submitted). The missing feature is a link to the log view for directories.
A few Autohotkey scripts
I decided to post the source for a few Autohotkey scripts a couple of days ago:
- GW Tonic Bot : This one is a bot to drink tonics for you in Guild Wars to help you get your Party Animal title. It maps back and forth between your Guild Hall and drinks 2 tonics (yes, 2 tonics because of a bug in GW) each time it stops.
- GW Drunkard Bot : This one was meant to drink alcohol at specific intervals to achieve optimal points towards your Drunkard title. This was made obsolete by the March 3, 2011 update. You can now click them (or have an autoclicker click them) as fast as you want.
- Generic Autoclicker : This one can be for any kind of automated clicking, it just clicks (or double clicks) where you tell it to at an interval you specify.
Note that I haven't tested them in IronAHK, only Autohotkey on Windows. Also note that it's also easy to convert these to an .exe file if you don't want to install Autohotkey. And if a non-techie is reading this, I'm happy to provide that for you. Just leave a comment below.
Also feel free to comment (or fork) either of these scripts if you have improvements. Some people have found that the delay between mappings in the tonic bot is not long enough for slower internet connections and so you have to tell it to drink more tonics than you'd think (since some clicks will be wasted).
Also feel free to comment (or fork) either of these scripts if you have improvements. Some people have found that the delay between mappings in the tonic bot is not long enough for slower internet connections and so you have to tell it to drink more tonics than you'd think (since some clicks will be wasted).
Monday, August 1, 2011
Musical Amateurism
Warning: the following is at rant on the state of pop music that shamelessly derides the music industry. Reader discretion is advised.
I've been thinking about music and musical instruments lately. And it occurred to me how odd our current musical experience is. One of the oldest recorded songs in history dates back to about 1400BCE, but it's likely unrecorded music existed long before that. My point being that music has always been a very pervasive element in our cultures. It was performed by average Joes for average Joes, where many (if not all) of the listeners actively took part in the experience. But this is not reflected in our current musical culture. We now only passively engage with the music with our stereos, ipods, etc. And it is largely no longer done by amateurs. Teams of professionals (of whom the actual artist is often only a small part, as in the case of pop singles). And the industry that has been built to protect this corporatizing (like the RIAA) and wanting money practically every time someone sings one of their songs is also downright odd, when viewed in the context of most of our musical history. How can you copyright something so quintessential to the human experience? (By the way, the RIAA has yet to share a single penny of the settlements they've won with the artists they're supposedly protecting, I refuse to buy an album released by the RIAA).
I think this decline in musical amateurism started with the end of the Baroque period of music, when music began being performed by people whose profession was music and the instruments of choice became more complex (for example, the decline of the recorder). This was partly because of the growing world economy that made more leisure time possible. Whereas in the past, as my Western Civ professor put it, "Most of your ancestors were hungry most of the time." Aristocracies were falling, and more power (politically and economically) was making its way into the hands of the common man. But even in this period of history, folk music was still alive and well. And although amateur musicians were no longer the sole source of music, they were still a significant source of it. This continued for some time, with professional music comprising a larger and larger percentage of the music consumed by the population. Things changed again, and rather dramatically, with the advent of recorded music. In the past, it was still very typical for a household to have a means of producing their own music. A woman was considered more marriageable if she were able to provide this service for her home. The piano was the most popular choice for this, in my opinion because it arguably has a greater capacity to make a single musician a one man band than any other instrument. There were other factors as well. The depression hit, which drove down piano sales considerably, and recorded musical devices became more and more inexpensive. When these devices became relatively mainstream, it gave households the ability to have music without the need of any musical talent or the cost of maintaining a musical instrument (pianos generally need tuned about twice a year). This process, as most of you already know has been accelerated many times in recent history, with the advent of radio, CDs, portable players, and the MP3.
While I do still spurn what the pop single culture has become, with its uncreative and sometimes downright unpleasant lyrics, its increasingly heavy use of autotuners, and seeming desire to sell sex rather than musical talent, I do still enjoy the occasional good beat. What I'm really coming to sense as far as what's been lost over time is musical amateurism. These days, with the world as your critic, you can't even watch a Youtube video of a little kid plucking out their first tune without reading a comment below of "this kid sukx". Folk is essentially dead (at least in America). The closest thing you can get to this amateurism (aside from high school recitals) is Indie. And several of these bands are just corporate wannabes. And because of this, it seems to be hard to find bands willing to break the mold being created by the professionals (you might find some on Jamendo). This lapse in creativity and morality is disturbing. But so is how passive we've become in our interactions. This goes for all our interactions like texting your mom instead of talking face to face, but also for our music. Unless you count what establishments largely built on lecherous recreation, like clubbing joints, our interaction with music and musically with each other is largely minimal. I'm not saying that I'd like all such establishments shut down and the music industry to die. Maybe it still has a place in our society, I don't know. But I would like to see people become more involved in the musical process and increasing the level of creativity in the music listened to by the general populace. But If singing about getting probed by aliens or getting excited by chains and whips represents the pinnacle of creativity in popular music then
I've been thinking about music and musical instruments lately. And it occurred to me how odd our current musical experience is. One of the oldest recorded songs in history dates back to about 1400BCE, but it's likely unrecorded music existed long before that. My point being that music has always been a very pervasive element in our cultures. It was performed by average Joes for average Joes, where many (if not all) of the listeners actively took part in the experience. But this is not reflected in our current musical culture. We now only passively engage with the music with our stereos, ipods, etc. And it is largely no longer done by amateurs. Teams of professionals (of whom the actual artist is often only a small part, as in the case of pop singles). And the industry that has been built to protect this corporatizing (like the RIAA) and wanting money practically every time someone sings one of their songs is also downright odd, when viewed in the context of most of our musical history. How can you copyright something so quintessential to the human experience? (By the way, the RIAA has yet to share a single penny of the settlements they've won with the artists they're supposedly protecting, I refuse to buy an album released by the RIAA).
I think this decline in musical amateurism started with the end of the Baroque period of music, when music began being performed by people whose profession was music and the instruments of choice became more complex (for example, the decline of the recorder). This was partly because of the growing world economy that made more leisure time possible. Whereas in the past, as my Western Civ professor put it, "Most of your ancestors were hungry most of the time." Aristocracies were falling, and more power (politically and economically) was making its way into the hands of the common man. But even in this period of history, folk music was still alive and well. And although amateur musicians were no longer the sole source of music, they were still a significant source of it. This continued for some time, with professional music comprising a larger and larger percentage of the music consumed by the population. Things changed again, and rather dramatically, with the advent of recorded music. In the past, it was still very typical for a household to have a means of producing their own music. A woman was considered more marriageable if she were able to provide this service for her home. The piano was the most popular choice for this, in my opinion because it arguably has a greater capacity to make a single musician a one man band than any other instrument. There were other factors as well. The depression hit, which drove down piano sales considerably, and recorded musical devices became more and more inexpensive. When these devices became relatively mainstream, it gave households the ability to have music without the need of any musical talent or the cost of maintaining a musical instrument (pianos generally need tuned about twice a year). This process, as most of you already know has been accelerated many times in recent history, with the advent of radio, CDs, portable players, and the MP3.
While I do still spurn what the pop single culture has become, with its uncreative and sometimes downright unpleasant lyrics, its increasingly heavy use of autotuners, and seeming desire to sell sex rather than musical talent, I do still enjoy the occasional good beat. What I'm really coming to sense as far as what's been lost over time is musical amateurism. These days, with the world as your critic, you can't even watch a Youtube video of a little kid plucking out their first tune without reading a comment below of "this kid sukx". Folk is essentially dead (at least in America). The closest thing you can get to this amateurism (aside from high school recitals) is Indie. And several of these bands are just corporate wannabes. And because of this, it seems to be hard to find bands willing to break the mold being created by the professionals (you might find some on Jamendo). This lapse in creativity and morality is disturbing. But so is how passive we've become in our interactions. This goes for all our interactions like texting your mom instead of talking face to face, but also for our music. Unless you count what establishments largely built on lecherous recreation, like clubbing joints, our interaction with music and musically with each other is largely minimal. I'm not saying that I'd like all such establishments shut down and the music industry to die. Maybe it still has a place in our society, I don't know. But I would like to see people become more involved in the musical process and increasing the level of creativity in the music listened to by the general populace. But If singing about getting probed by aliens or getting excited by chains and whips represents the pinnacle of creativity in popular music then
Tea is tea
So, it turns out the dude at Teavana was right: all teas (e.g. black, white, green, oolong, etc) are all prepared (check out the cool chart) from the same plant (Camellia Sinensis). Naturally, this excludes Rooibus and herbal teas. But this surprised me.
Speaking of tea, I've always found this story interesting about how tea came to be. The Bodhidharma was meditating soon after arriving in China for 9 years. At some point during this time, he dozed off for just a second. He was so frustrated at having broken his concentration that he cut off his eyelids so that he'd never be distracted again by sleep. Guan Yin (Buddhist bodhisattva of compassion) caused the eyelids to grow into tea plants, used by Buddhist practitioners to this day to prevent sleep from interrupting their meditations. The Japanese character for tea leaf is the same as that for eyelid.
Speaking of tea, I've always found this story interesting about how tea came to be. The Bodhidharma was meditating soon after arriving in China for 9 years. At some point during this time, he dozed off for just a second. He was so frustrated at having broken his concentration that he cut off his eyelids so that he'd never be distracted again by sleep. Guan Yin (Buddhist bodhisattva of compassion) caused the eyelids to grow into tea plants, used by Buddhist practitioners to this day to prevent sleep from interrupting their meditations. The Japanese character for tea leaf is the same as that for eyelid.
Friday, December 17, 2010
Maven 3 & profiles.xml
There are some pretty cool things in Maven 3 (although mixins and global dependency exclusions have been tabled until 3.1). Matt Raible talks about some of them here. Significant points include dramatically increased performance (50% to 400% faster), unspecified plugin versions will pull the latest version and not snapshot versions (though it's best to be explicit about plugin versions), also Sonatype has developed Maven Shell and polyglot Maven to work with Maven 3.
There are, however, some compatibility concerns when moving from Maven 2.x. And not all plugins work yet. (Most notably they're refactoring the Site Plugin so it's not completely working yet). But the Maven team intends the new release to be usable as a drop-in replacement for Maven 2 (though this won't be the case for Maven 3.1).
Most changes for compatibility seemed pretty trivial. The biggest thing I see preventing Maven 3 from being a drop-in replacement for Maven 2 was their decision to remove support for profiles.xml. This was documented in MNG-4060, though not much discussed there. A few people have complained about this already here and it was discussed a little here. I haven't seen much justification for this, other than it's supposed to be difficult to test. Though I'm not sure why it'd be much harder to test than the use of profiles in the pom.xml. But the Maven team seems for whatever reason fairly committed to this idea, despite one of their committers (Milos Kleint) disagreeing with their position.
People use profiles for a variety of things. Where I work, they are commonly used for environment settings. For example, which version of a particular web service or database to use in prod, qa, etc. But also for which version of that service or database to use for a particular developer's sandbox (another common difference between developers is their log level). These typically use Maven filtering in conjunction with external profiles to accomplish this. These profile properties are also kept in our SCM so if something used by all developer's sandbox, it is easily changeable and transparent to all developers on the project. It is currently impossible to run Maven 3 in this way.
We are not entirely without options when it comes to addressing this, but none of the solutions in my opinion is as nice as the stable, built-in profiles.xml feature. Recently, I've asked if there is some other mechanism I should be using to accomplish this. To date, I've not seen anyone fully explore this issue that I think is important for Maven 3 going forward. So that's what I did here. If you'd like any of the sample projects I created for this exploration, just drop me a line. Maybe I'll put them up on GitHub or something at some point. So without further ado, here are the options I've found and their pros & cons.
pom.xml
mvn -P developer1 <goal>
Variations
1. Multiple pom.xml files could be checked into the project to cut down on the clutter inside the main pom.xml.
As one commenter in the mailing list noted, some developers have a fear of changing their settings.xml (even if they should be comfortable with this) and would prefer to simply change a few properties. But this should make us pause to make sure there's nothing we're using profiles.xml for when we should actually be using settings.xml.
mvn -s path/someSettingsFile.xml <goal>
and create a file like
developer1.xml
Variations
1. Use profiles to select the properties file
This could be invoked in the standard way:
mvn -P developer1 <goal>
And your pom might look like
pom.xml
2. Use a variable to select the properties file
In my sample, the invocation would be
mvn -Dprofile=developer1 <goal>
And the POM would be like
pom.xml
I still think removing profiles.xml support is bad since the intent was to keep backward compatibility, thus making pointing my M2_HOME to Maven 3 a bit painful when working on old and new projects. It also seems a bit strange that they removed support for profiles.xml when they but not for profiles. It was nice to be able to have those external to the POM.
However, for my (and probably the gentleman on Nabble also) use case, Maven filtering with profiles probably may not have been the right idea in the first place.
There are, however, some compatibility concerns when moving from Maven 2.x. And not all plugins work yet. (Most notably they're refactoring the Site Plugin so it's not completely working yet). But the Maven team intends the new release to be usable as a drop-in replacement for Maven 2 (though this won't be the case for Maven 3.1).
Most changes for compatibility seemed pretty trivial. The biggest thing I see preventing Maven 3 from being a drop-in replacement for Maven 2 was their decision to remove support for profiles.xml. This was documented in MNG-4060, though not much discussed there. A few people have complained about this already here and it was discussed a little here. I haven't seen much justification for this, other than it's supposed to be difficult to test. Though I'm not sure why it'd be much harder to test than the use of profiles in the pom.xml. But the Maven team seems for whatever reason fairly committed to this idea, despite one of their committers (Milos Kleint) disagreeing with their position.
People use profiles for a variety of things. Where I work, they are commonly used for environment settings. For example, which version of a particular web service or database to use in prod, qa, etc. But also for which version of that service or database to use for a particular developer's sandbox (another common difference between developers is their log level). These typically use Maven filtering in conjunction with external profiles to accomplish this. These profile properties are also kept in our SCM so if something used by all developer's sandbox, it is easily changeable and transparent to all developers on the project. It is currently impossible to run Maven 3 in this way.
We are not entirely without options when it comes to addressing this, but none of the solutions in my opinion is as nice as the stable, built-in profiles.xml feature. Recently, I've asked if there is some other mechanism I should be using to accomplish this. To date, I've not seen anyone fully explore this issue that I think is important for Maven 3 going forward. So that's what I did here. If you'd like any of the sample projects I created for this exploration, just drop me a line. Maybe I'll put them up on GitHub or something at some point. So without further ado, here are the options I've found and their pros & cons.
1. Fork Maven and put the feature back in
Maybe it's my cynical nature, but this was actually the first thing that came to my mind. But I don't know that very many people would feel comfortable running a patched version of Maven. Plus, I'd want to keep forking them to keep getting all the other goodies they add, which makes a lot of work for me. Then I thought of submitting a patch to Maven for this. But when I found out the decision was pretty deliberate and not simply a lack of resources, I backed off that idea.| Pros | Cons |
| It's the way Maven should be | A lot of work |
| Who's brave enough to use it? |
2. Stick with Maven 2
Hey, there's nothing wrong with being old fashioned. There's strong logic to the "If it ain't broke, don't fix it" argument. Some people are even still happily on the 2.0.x branch rather than the 2.2.x branch.| Pros | Cons |
| The least work of any other solution | No Maven 3 goodies |
3. Place all profiles properties in the POM
POMs in Maven 3 still use a <modelVersion>4.0.0</modelVersion>. There for you could put everything inside it likepom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.foo</groupId>
<artifactId>pomProfileTest</artifactId>
<version>1.0</version>
<properties>
<!-- these are defaults, they can be overridden with a settings.xml -->
<javaVersion>1.5</javaVersion>
<junitVersion>4.8.2</junitVersion>
<sourceEncoding>UTF-8</sourceEncoding>
<resourceEncoding>UTF-8</resourceEncoding>
<profile>dev</profile>
<prop1>null</prop1>
<prop2>null</prop2>
</properties>
<profiles>
<profile>
<id>developer1</id>
<properties>
<prop1>prop1Value</prop1>
<prop2>prop2Value</prop2>
</properties>
</profile>
<profile>
<id>developer2</id>
<properties>
<prop1>anotherProp1Value</prop1>
<prop2>anotherProp2Value</prop2>
</properties>
</profile>
</profiles>
<!-- ... -->
</project>
mvn -P developer1 <goal>
| Pros | Cons |
| Simple to implement: scripts can continue to invoke Maven in the current way | Clutters POM, particularly troublesome since the POM is also deployed. |
| Also works with Maven 2 |
1. Multiple pom.xml files could be checked into the project to cut down on the clutter inside the main pom.xml.
4. Place all an environment's (or developer's) settings in a single settings.xml
This seems to be Maven's official answer on the subject. For things that are common across many projects, this might be a decent solution. But for the many project specific settings (e.g. a db.url property), you'd have to make sure they are named uniquely across all projects so as not to conflict with each other. This makes for a real maintenance problem.As one commenter in the mailing list noted, some developers have a fear of changing their settings.xml (even if they should be comfortable with this) and would prefer to simply change a few properties. But this should make us pause to make sure there's nothing we're using profiles.xml for when we should actually be using settings.xml.
| Pros | Cons |
| Maven's official solution | Uniquely named properties causes maintenance issues |
| Also works with Maven 2 | Changes not normally visible to all developers |
5. Use separate settings.xml files
You can specify a different user settings file withmvn -s path/someSettingsFile.xml <goal>
and create a file like
developer1.xml
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd">
<profiles>
<profile>
<id>developer1</id>
<properties>
<!-- global properties -->
<siteLocation>file://${user.dir}/site</siteLocation>
<!-- project specific properties -->
<prop1>prop1Value</prop1>
<prop2>prop2Value</prop2>
</properties>
<!-- ... -->
<profile>
<profiles>
</settings>
| Pros | Cons |
| Little profile clutter in POM | Massive clutter & overhead in profile settings file, as all your normal settings.xml things are now in each profile settings file |
| Checking all these settings files in allows developers to make sure they're all using and deploying to the same repos | profile settings are machine-dependent since <localRepository/> is also in settings file. |
| Also works with Maven 2 |
6. Use the Properties Maven Plugin
The Properties Maven Plugin allows for properties files to be loaded (and saved) just as if you had used <properties/> in the pom.xml itself.| Pros | Cons |
| Properties are cleanly externalized | Plugin is considered an alpha version |
| Also works with Maven 2 |
Variations
1. Use profiles to select the properties file
This could be invoked in the standard way:
mvn -P developer1 <goal>
And your pom might look like
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.foo</groupId>
<artifactId>propertiesProfileTest</artifactId>
<version>1.0</version>
<properties>
<!-- these are defaults, they can be overridden with a settings.xml -->
<javaVersion>1.5</javaVersion>
<junitVersion>4.8.2</junitVersion>
<sourceEncoding>UTF-8</sourceEncoding>
<resourceEncoding>UTF-8</resourceEncoding>
<profile>dev</profile>
<prop1>null</prop1>
<prop2>null</prop2>
</properties>
<profiles>
<profile>
<id>developer1</id>
<properties>
<profile>developer1.properties</profile>
</properties>
</profile>
<profile>
<id>developer2</id>
<properties>
<profile>developer2.properties</profile>
</properties>
</profile>
</profiles>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${project.basedir}/filters/${profile}</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<!-- ... -->
</project>
| Pros | Cons |
| Standard way for selecting profile | POM now is cluttered with mapping profiles to properties files |
2. Use a variable to select the properties file
In my sample, the invocation would be
mvn -Dprofile=developer1 <goal>
And the POM would be like
pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.foo</groupId>
<artifactId>propertiesProfileTest</artifactId>
<version>1.0</version>
<properties>
<!-- these are defaults, they can be overridden with a settings.xml -->
<javaVersion>1.5</javaVersion>
<junitVersion>4.8.2</junitVersion>
<sourceEncoding>UTF-8</sourceEncoding>
<resourceEncoding>UTF-8</resourceEncoding>
<profile>dev</profile>
<prop1>null</prop1>
<prop2>null</prop2>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${project.basedir}/filters/${profile}.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<!-- ... -->
</project>
| Pros | Cons |
| Little profile clutter in POM | No standard way of selecting profile |
Conclusion
I still really wish the Maven folks would change their mind on this. But until then (unless you're sticking with Maven 2 -- which might not be a bad idea at least for now because of plugin incompatibilities), the best option seems to me to use the Maven Properties Plugin, either with a property or with a profile. (Personally, I'm leaning to the profile option beacuse I think the fact it can be invoked in a standard way is worth the extra POM clutter). Though it is technically an alpha version, it seemed to work fine for me and I believe Maven's decision to remove support for profiles.xml will cause people to flock to this plugin, and therefore likely to only increase its stability. Of course, IDE support for this practice is another question.Conclusion Part 2
I do feel obligated to mention that the practice of using Maven filtering for things like database URLs where I work is actually changing to use runtime properties instead. (Generally by building a property reader class using java.util.Properties to read different properties files based on the name passed with -Denv=<environmentName>). This has the advantage (besides working with Maven 3) of not requiring separate deployments just for environment differences or redeploys for changes to an environment property.I still think removing profiles.xml support is bad since the intent was to keep backward compatibility, thus making pointing my M2_HOME to Maven 3 a bit painful when working on old and new projects. It also seems a bit strange that they removed support for profiles.xml when they but not for profiles. It was nice to be able to have those external to the POM.
However, for my (and probably the gentleman on Nabble also) use case, Maven filtering with profiles probably may not have been the right idea in the first place.
Sunday, October 24, 2010
My Review of Medal of Honor (2010)
I was on the fence about getting this game. If they didn't offer guns that were only available through pre-ordering, I may not have even gotten the game. But this coupled with the bonus sniper rifle for having BC2 VIP, and my lack of interest in the upcoming CoD game nudged me to the purchasing side of the fence. Oh, one other bonus is that you get in on the beta for Battlefield 3 (if that's important to you). And probably there'll be other bonuses through EA's Gun Club.
First off: everything mediocre I've read about this game is true. The single player is unremarkable in almost every way, it does suffer from a few scripting issues (I don't think worst than other MoH titles I've played, but our standards have gone up since then), and the graphics stutter in a few places (seemed to me to be mostly around save points). On the plus side, the sliding into cover system they have in single player is pretty cool. Unfortunately, this isn't available in multiplayer. Which is the other unfortunate thing about this game: how disconnected the singleplayer is from the multiplayer. It was done by two teams, in two countries, with two different engines, and they seemed to communicate very little between them during development. It's amazing how much time (3 years) was spent on the singleplayer and yet it still rings pretty hollow at the end of the day. Interestingly, EA's stock dropped 6% on launch day, due to investors being worried by the mediocre reviews. There are a couple of interesting levels, but nothing we haven't really seen before and no level sticks out in my memory as "woah, that was awesome!". There's a level where you get to use attack helicopters, a sniping level, a level with ATVs, and the cinematics are pretty good (and you could skip them if you wanted to, which I've not seen in recent games). The storyline could have been a little tighter (for example the incompetent, friendly-fire causing general is all but forgotten later in the game), but I did like that it was grittier and had fewer Jack Bauer-esque moments than MW2's storyline.
For the mulitiplayer side: It's actually pretty good, and I've found the description as a hybrid of BC2 and MW2 to be true. This game differs from BC2 in that there is limited destructibility (one of the coolest things about BC2), and most game modes don't have any vehicles (the other really cool thing about BC2), although there are light tanks in one of the modes. There are perks like in MW2, but you don't roll through them in the frantic pace that seems to dominate MW2. The guns do seem more balanced than either of the other 2 games. The maps are bigger than MW2, but smaller than BC2. One thing that is unique about their perk system is that every time you unlock a perk, you can choose between a defensive and an offensive action. Defensive actions include stuff like enemy radar and flak vests for your buddies, and offensive actions involve things like mortar strikes and rocket strikes. But unlike MW2, then chain of perks is not configurable. Like BC2 and MW2, you unlock new guns and stuff for your guns as you progress ranks by earning points. The number of rounds to take down an opponent is about the same as BC2 (they have a hardcore mode too, which I haven't tried yet).
The only major downside to the multiplayer is the spawn points. They're awful. In BC2, you'd only get popped on spawn if you spawned on a buddy about to get pwnd. In this game I find myself spawning into a mortar strike or into a gang of enemies fairly often. Which, needless to say, is intensely aggravating (particularly after it happens 4 times in a row -- not uncommon since kills with a perk count towards the next perk). In some modes, you can spawn back to your base instead of the front, but not all modes have this idea (for example their version of Death Match). But sometimes you can use this to your advantage. On some maps, I've been able to run up to one of their spawn points with my M60 a few seconds into the game and wipe half their team before they can put a stop to my mayhem. A dirty trick, but it made me giggle.
Overall, if you have to choose between this game and BC2 and MW2, I'd say get either BC2 or MW2 (depending on your playing style). But if you already have those games and are looking for something with a little less Vietnam and RC cars, this might make for a good distraction until something better comes along. It's definitely not a terrible game, but its not an amazing game either. The worst thing about it is realizing what could have been...
First off: everything mediocre I've read about this game is true. The single player is unremarkable in almost every way, it does suffer from a few scripting issues (I don't think worst than other MoH titles I've played, but our standards have gone up since then), and the graphics stutter in a few places (seemed to me to be mostly around save points). On the plus side, the sliding into cover system they have in single player is pretty cool. Unfortunately, this isn't available in multiplayer. Which is the other unfortunate thing about this game: how disconnected the singleplayer is from the multiplayer. It was done by two teams, in two countries, with two different engines, and they seemed to communicate very little between them during development. It's amazing how much time (3 years) was spent on the singleplayer and yet it still rings pretty hollow at the end of the day. Interestingly, EA's stock dropped 6% on launch day, due to investors being worried by the mediocre reviews. There are a couple of interesting levels, but nothing we haven't really seen before and no level sticks out in my memory as "woah, that was awesome!". There's a level where you get to use attack helicopters, a sniping level, a level with ATVs, and the cinematics are pretty good (and you could skip them if you wanted to, which I've not seen in recent games). The storyline could have been a little tighter (for example the incompetent, friendly-fire causing general is all but forgotten later in the game), but I did like that it was grittier and had fewer Jack Bauer-esque moments than MW2's storyline.
For the mulitiplayer side: It's actually pretty good, and I've found the description as a hybrid of BC2 and MW2 to be true. This game differs from BC2 in that there is limited destructibility (one of the coolest things about BC2), and most game modes don't have any vehicles (the other really cool thing about BC2), although there are light tanks in one of the modes. There are perks like in MW2, but you don't roll through them in the frantic pace that seems to dominate MW2. The guns do seem more balanced than either of the other 2 games. The maps are bigger than MW2, but smaller than BC2. One thing that is unique about their perk system is that every time you unlock a perk, you can choose between a defensive and an offensive action. Defensive actions include stuff like enemy radar and flak vests for your buddies, and offensive actions involve things like mortar strikes and rocket strikes. But unlike MW2, then chain of perks is not configurable. Like BC2 and MW2, you unlock new guns and stuff for your guns as you progress ranks by earning points. The number of rounds to take down an opponent is about the same as BC2 (they have a hardcore mode too, which I haven't tried yet).
The only major downside to the multiplayer is the spawn points. They're awful. In BC2, you'd only get popped on spawn if you spawned on a buddy about to get pwnd. In this game I find myself spawning into a mortar strike or into a gang of enemies fairly often. Which, needless to say, is intensely aggravating (particularly after it happens 4 times in a row -- not uncommon since kills with a perk count towards the next perk). In some modes, you can spawn back to your base instead of the front, but not all modes have this idea (for example their version of Death Match). But sometimes you can use this to your advantage. On some maps, I've been able to run up to one of their spawn points with my M60 a few seconds into the game and wipe half their team before they can put a stop to my mayhem. A dirty trick, but it made me giggle.
Overall, if you have to choose between this game and BC2 and MW2, I'd say get either BC2 or MW2 (depending on your playing style). But if you already have those games and are looking for something with a little less Vietnam and RC cars, this might make for a good distraction until something better comes along. It's definitely not a terrible game, but its not an amazing game either. The worst thing about it is realizing what could have been...
Subscribe to:
Posts (Atom)