Warning: include() [function.include]: Unable to access /var/www/html/rogue-development/blog2/wp-content/advanced-cache.php in /var/www/html/rogue-development/blog2/wp-settings.php on line 62

Warning: include(/var/www/html/rogue-development/blog2/wp-content/advanced-cache.php) [function.include]: failed to open stream: No such file or directory in /var/www/html/rogue-development/blog2/wp-settings.php on line 62

Warning: include() [function.include]: Failed opening '/var/www/html/rogue-development/blog2/wp-content/advanced-cache.php' for inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/html/rogue-development/blog2/wp-settings.php on line 62

Notice: add_option was called with an argument that is deprecated since version 2.3 with no alternative available. in /var/www/html/rogue-development/blog2/wp-includes/functions.php on line 3468

Notice: register_sidebar_widget is deprecated since version 2.8! Use wp_register_sidebar_widget() instead. in /var/www/html/rogue-development/blog2/wp-includes/functions.php on line 3382

Notice: register_widget_control is deprecated since version 2.8! Use wp_register_widget_control() instead. in /var/www/html/rogue-development/blog2/wp-includes/functions.php on line 3382
Marc « Marc’s Musings


Notice: get_author_name is deprecated since version 2.8! Use get_the_author_meta('display_name') instead. in /var/www/html/rogue-development/blog2/wp-includes/functions.php on line 3382

Author Archive for Marc

Page 3 of 25

One week with Droid – my impressions

So it’s been a week since I got my Verizon Droid.  How’s it been?

I had been using one of the G1 phones on TMobile’s network.  It was running Android 1.6, the new Droid is running Android 2.0.  Let’s compare Droid to that first.

Let me start by saying, they’re not all that dissimilar.  The one plus the G1 had was the keyboard was easier to use.  It actually had separate physical buttons whereas the Droid has them all on a single etched piece of rubbery plastic.  The droid is faster, has more memory and storage, and looks better – all by a lot.  Holding the phone if feels like it’s engineered and manufactured well.  Holding the G1, it kind of felt like a toy.

I haven’t had any problems finding or running any apps.  All the ones I’ve tried have been great.

The new Google Maps with navigation is amazing.  Better than my Garmin stand alone GPS unit.  It’s got “layers” now that can overlay all kinds of things.  Some of my favorites include traffic and Wikipedia.  The Wikipedia layer shows all of the Wikipedia references on a map.  When looking around my home, there’s maybe a dozen points listed.  I’m hoping a Geocaching app takes advantage of that layer functionality soon.

The battery life seems good.  I used the navigation app for an hour and a half on my commute to work one day.  That includes the screen being on the entier time, GPS updates contantly, and lots of network traffic.  As well as the speaker telling me the directions and a traffic overlay showing me where the road would slow down.  At work, I left all of the services (bluetooth, wifi, gps) all day long.  I consciously tried to use it as much as possible.  At the end of the day there was still 15% battery life left.  Normally, I plug it in while driving, but it’s nice to know I dont have to.

So, if those things were the only differences from my old phone to this one, the $200 TMobile cancellation penalty, plus the $200 new phone cost might not have been worth it.  But there was one major other difference.  The network.  Verizon is amazing compared to TMobile.  I’ve used the same speed-testing app on both phones in a variety of situations.  The fastest speed I ever saw with TMobile was around 300kbs.  When I was at my house, it never went over 5kbs, usually in the 1-2 range.  With Verizon, the slowest I’ve seen is around 300kbs.  At my house, I average 500kbs.  That over a 25000% increase.  When in the office at work, it wasn’t worth even trying to get a data signal with TMobile.  With verizon, it works perfectly.  This is the biggest single selling point of the entire experience for me and I’m am a very happy customer.  This speed changed the way I use my phone from the G1 tot he Droid as much as the G1 changed the way I use a phone from a dumb-phone to a smart phone.

Cost-wise the monthly plans between TMobile and Verizon are about the same.  I do get a 17% discount because my company has a contract with Verizon so your price may varry.

I heard a great Droid radio ad today.  This one below is similar, but the Radio one was better.

Scheduling meetings

Scheduling meetings through outlook might be one of the worst practices I need to deal with on a daily basis.  It saves us a ton of time in the meeting-planning department but has huge drawbacks.

Problem number one, it’s WAY too easy to schedule a meeting with someone.  Since the bar is lower, more meetings happen.  Since there’s more meetings, they’re often individually less valuable.  Since they’re less valuable people don’t treat them with the respect they deserve.  Nobody prepares beforehand.  Meeting agendas are the exception, not the rule.

Secondly, it’s not an efficient way to schedule a meeting.  Wait, let me revise that slightly.  It’s not an efficient way to schedule a set of meetings.  The normal process that is often used is to put everyone on an invitation.  Find a block of time everyone is available.  Book it.  Later, that process is repeated for the next meeting.  Even later it’s repeated again.  Since different people go to different meetings, individual schedules get “fragmented”.  Back in the days of personal assistants (or back then I guess the term was “secretaries”), they would handle the process of defragmenting schedules to make them make more sense.  This leads to situations when individuals have an hour meeting, an hour to work, an hour meeting, an hour to work, etc.  Without bigger blocks of time to work it’s impossible to tackle certain problems.  Even worse, a high priority meeting might get pushed back because other meetings were scheduled earlier.

Combine those two problems, and it actually gets hard to book a meeting.  Since there are a lot of them.  And since there is fragmentation in people’s schedules, finding an open block that everyone can join can be really hard to do.  This means scheduling happens further and further out.  If you need to talk about something with 10 people and the only time slot to get them all in a room is a week away, that sucks.

A side-effect of this is that when you receive a meeting request, you often really feel obligated to accept it.  Especially if the sender knows you have a free block of time.  That means you’re not asking yourself  ”Is me attending this meeting the best way for me to spend my time to advance/improve/help the organization?”  I think we should be asking that question all the time!

How to define an ideal solution?

If we’re going to explore other options, it’d be helpful to have some evaluation criteria.  Here’s what I would look for in a meeting scheduling system (in my order of priority).

  1. Ability to schedule meetings without conflicts.  (including resource and people conflicts)
  2. Schedule more important meetings sooner than less important ones.
  3. Minimize the number of chunks of free time each user has.  (In other words, maximize the average length of non-meeting time)  This one is really important for knowledge-workers.
  4. Encourage productive meetings.   (Clear purpose, set agenda, everyone comes prepared … )

What other properties might an ideal solution have?

So what’s one solution?

First, here’s a technical solution.

The first problem of meetings being too easy to schedule is tough.  It really requires training people to act differently.  Without designing a technical solution that somehow discourages meetings, I’m not sure what to do about that.

The second problem could have a technical solution.  Imagine a “smart” scheduling system.  You need to schedule a meeting?  Submit the details of the meeting to some computer system.  Tell it

  1. Who needs to attend
  2. Any time constraints that must be upheld.
  3. What resources do you need.
  4. How important is it?

But the important thing is that you don’t specify when it happens.  (There may be time-constraints for some meetings that do dictate a time.  Like if a client is arriving, it has to happen in a given time slot.  Or if there is a release planned for thursday, the release planning meeting must happen before thursday.)

Then the system is free to schedule that meeting whenever is “best” by some smart criteria.  It tries to maximize individual people’s free time blocks.  It tries to schedule more important meetings sooner.  It moves existing meetings when new ones are scheduled so there’s always an optimal solution planned.

The downside?  Meetings move.  It’s hard to plan ahead.  Someone needs to develop a complex scheduling system.  The time that meetings happen becomes “voodoo magic” to some people.  It’s possible to game the system.  It’s not flexible.

Solution #2

Now, here’s an organizational solution that I want to try out here at TSP.

1) Meetings that HAVE to happen at a certain date/time are scheduled as normal.  Got outsiders coming in?  Meeting to watch the pat’s game?  Go ahead and schedule those as before through outlook.  Hopefully that’s the minority of meetings for you.  (If you’re the guy meeting with outside clients all day long, you’re pretty much screwed any way you look at it.)  A certain class of exceptional or emergency-meeting falls in here too.

2) Got a meeting that doesn’t HAVE to happen at a certain date/time?  You’re not allowed to just schedule that through outlook.  Instead, at your daily scrum we schedule those as a group.  With one more constraint.  You only schedule meetings for tomorrow.  It’s either important enough to schedule for tomorrow, or it isn’t.  That’s a much easier, concrete decision to make than scheduling a meeting next-week.  Some meetings lower on the priority list might not fit.  That’s fine, try to get them on the list again tomorrow.

To actually create this schedule, you’re likely looking at outlook as a group.

Benefits:

  1. You can intelligently schedule meetings.  Since you’re only looking at a day at a time and you’re considering all the meetings together it’s easy.
  2. You get to decide which meetings are more important than others.
  3. You get to weigh the benefits of a meeting against non-meeting things.  It’s easy to schedule a meeting a week in advance for a trivial matter.  It’s really hard to schedule that meeting *tomorrow* if there’s more important things to do.
  4. It makes people think about meetings and whether or not they have to happen.
  5. Since a meeting you’re invited to is only ever a day away, it’s more on your mind and you might prepare for it instead of being surprised by an outlook reminder.

Down sides:

  1. Boy does this require a lot of buy-in from everyone involved.
  2. Participants have limited time to prepare (The person calling the meeting has as much time as they need to prepare since they could just wait another day if needed)
  3. Since your group is scheduling a day in advance, it can be hard to get ahold of resources that other groups might be scheduling weeks in advance.  There’s likely solutions to that, but I’ll stay away from them for now.

I’d only consider using this for larger (4+ people) meetings.  Still feel free to have impromptu talks whenever they’re needed.  Still feel free to try an resolve issues at the scrum, or by sticking around after your scrum.  In fact it might encourage a quick post-scrum discussion instead of a meeting.

Side-Note: I heard a rumor that Warren Buffet only schedules meetings a day in advance.  I have no idea if if is true or not.  But that’s where I got the idea from.

Caveats

Replace “Outlook” with any other “dumb” scheduling solution out there.  Lotus Notes?  Google Calendar?  Whatever.

Don’t complain that I call it outlook and not Exchange or whatever the entire-system should be called.

My solution assumes you have a short daily meeting.  It would suck to have to introduce that if you don’t.

What else?

There has to be better solutions to this.  What do you do?

TSP Build Notification Board

A couple posts back I blogged about playing around with an Arduino.  Since then I’ve completed my first project, a Build Notification Board for work. It sits in my office window facing the main part of our office building.

At work, whenever a developer submits a change to a project we automatically make a build to make sure nothing goes wrong.  This board gives us the current status of four different automated builds that happen on those cruise control servers.  The green light indicates that the last build was successful (it switches to red if it failed).  The blue light lets us know if it’s currently building (it does a nice pulsing fade in/out).

On any failure, a flag is also risen from the top of the board.

There’s two meters at the top.  The first one shows an overall project completion (that’s manually entered by me right now).  The other one shows “communication density”.  Right now, it’s a random value that ticks up and down.  Eventually it’ll represent the volume of traffic on our project mailing lists.

The top gauge looks like this (The 0-180 scale is a bit of an internal joks that any fellow TSP employee would get):

The electronics are fairly simple.  4 pins of the arduino control the red/green lights.  4 pins control the blue lights.  One of them controls a servo that raises/lowers the flag, and two pins are for the two meters.

Besides that I have a switch on the back that activates “demo mode” that does some pretty flashing lights and raises the flag.  There are a couple status indicator lights that tell how the board is functioning back there as well.

The meters are 1970′s era amp-meters in the micro-amp range that I opened up and replaced the background label with customized print outs.  I was suprised to see that a simple resistor and PWM signal could control them accurately.  I was thinking I’d need a capactitor in there to even out the current.

Here’s the back of the board.  Normally, there is a panel that covers all this to make it look less like a fire hazard.  At the top you can see one of the meters.  Next to that is a small protoboard that the status lights, demo-switch and flag-servo are all soldered into.

If you follow the green wires down from there you’ll come to my Arduino board which is actually a lower-cost Seeduino that I bought so I could continue playing with my arduino for other projects.  One nice thing about the Seeduino is you can solder connectors directly to it.  I’ve got 2 8-pin connectors attached to it that connect all the lines I needed to the proto board below it through those rainbow-wires.  That second proto-board has the resistors for the blue lights and the connections for all of the lights on it.

To the left of all that is a structure that holds all of the lights, the lenses, and some dividers between the lights.  To control two lights with a single pin it was easier for me to put those resistors closer to the LEDs so that’s what you see there.

The black wire from the Seeduino to the foreground is a USB cable providing power and status updates.   On the computer it’s attached to there is an AIR application that queries status info from our cruise control servers and relays it to a program running on the seeduino.

Pulse Particles MXP

Sorry for a lack of posts recently, been really busy with project work. I’m on vacation next week, so I’m trying to get caught up on posts today.

Dominik Pesch over at 11com7 has created and sent me a .mxp package for Pulse Particles. This package adds the particle explorer as a new window within the Flash authoring environment and makes the component available from the standard libraries.  This could really make it easier for designer-types to use.

Download PulseParticlePackage.mxp (4mb)

Thanks Dominik!

Arduino fun

This morning I got to play with a recently purchased arduino board.  Let me tell you, these things are amazingly easy to use.  Everyone should give it a try at some point.  I’m not going to try to write a how-to or a tutorial right now, but let me illustrate just how easy this was.

1) Plug board into USB
2) Install Arduino software
3) Select example blink sketch (application) and upload

And suddenly you have a blinking LED (one is build onto the board).

So then I plugged in a little servo I had lying around, found the servo library.  Wrote a little sketch, and I was able to make the servo go to any position by communicating with my desktop computer over USB.  Total time, maybe half an hour.  Controlling servos isn’t the easiest thing in the electronics world since you have to worry about timing signals & whatnot.  But Arduino boils all that down to 2 or 3 lines of code.  Wow.

So next I set off to grab as3glue, which includes a serial port/tcp gateway so you can control the arduino through flash.  After maybe 20 minutes of tinkering I have an amazing high level API I can use in flash to control the board. (I ended up using arduino2flash instead of serproxy since serproxy wouldn’t work for me.)

Here’s a little AS3 snippet that uses a utility class I wrote to control 4 LED’s attached to the board from flash.

  1.  
  2.   arduino = new BuildBoardArduinoController()
  3.   TweenMax.to(arduino, 2, {led1:255, yoyo:0, ease:Quad.easeIn});
  4.   TweenMax.to(arduino, 2, {led2:255, yoyo:0, delay:1, ease:Quad.easeIn});
  5.   TweenMax.to(arduino, 2, {led3:255, yoyo:0, delay:2, ease:Quad.easeIn});
  6.   TweenMax.to(arduino, 2, {led4:255, yoyo:0, delay:3, ease:Quad.easeIn});
  7.  

That code causes each LED to fade in and out over and over. Wow… tweening physical computing? Neat.

3896960836_fa12762040

I had long been thinking about tinkering with one of these. If you have too, just do it. $30 for the board, and an hour of your time will get something working.

Next up, building a Build Notification system that will read in our CruiseControl status at work and let people know what’s going on.

Implementing interfaces in MXML

This is probably old news by now, but I just found out you can implement an interface in an MXML component. In the past I’ve always made a base class that implemented the interface and had the MXML inherit from that. A big waste of time for small components.

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"
  3.    implements="com.roguedevelopment.schedule.ui.ApplicationView">
  4. </mx:Canvas>

You just need to add an “implements” attribute to your root tag and specify the full class name. I’ll stick to the base class for large components, but this is the way to go for small, quick things.

Learning Flex 4…

I’ve been learning some Flex 4 stuff over the past week. One word… wow. Even without Catalyst, this is going to speed up my development a lot. Things like skinning a button with a complex code generated skin is now easy. I’ve been working on a site for my Wife’s budding photography business over at: Jessica Hughes Photography

It’s still a rough site, but I figure Flex 4 took me about the same amount of time to make it as it would have in Flex 3, but that includes learning about all these new features.

Profiling experience

Today, I happened to have Activity Monitor open while I was working on AgileAgenda and noticed something peculiar.  It was sucking up 200% of CPU time (multiple cores…)

So I fired up the application in the Flex profiler.  Let it sit for a minute, clicked the “Reset Performance Data” button, waited another few seconds, and then clicked the “Capture Performance Data” button.  The result was odd.

Nothing was actually in code I could touch and didn’t explain why it was happening.  There had to be something going on to peg out the CPU like that.  So I hit up the Flex preferences panel and found something I had forgotten about.

By default, the profiler excludes a whole bunch of flex and flash related classes from the profiler.  So I removed those exclusions and unchecked the box.  Went back to my profile window and low and behold, this is what I saw:

So now I had an idea of what was happening.  It looks like that indeterminate progress bar (which wasn’t on the screen anymore by that point) was sucking up some render time.

So I peeked at the ProgressBar flex code.  They’ve got a timer in there that gets started, and is stopped when the progress bar is set to invisible.  But that doesn’t end up accounting for cases where we just bump to a different parent object in a view stack.  So that timer sits there, happily spinning and consuming resources.

I added some code in to manually set the visiblity of the 2 indeterminate progress bars I had and ran.  Bamn, success.

So I learned (or re-learned?) two things today.

  1. When profiling, if you don’t see anything happening check your filters.
  2. Be very careful with indeterminate progress bars in flex.

Note: I got similar results both in the debugger (ADL) and when running the application stand-alone as a bundled application.

Nudger – my latest mini-project

A lot of times I find myself opening up Photoshop just so I can paste a screen shot of an application I’m working on in there and move some elements around to see where they look best.  I might grab a button and nudge it over to one side until it lines up somewhere.  And I use that info to go update my app.

Photoshop is way overkill.

So say hello to Nudger, a little AIR app I whipped up with ObjectHandles, Flex 4, and Moccasin

Nudger.air (1.3mb)

To use it, take a screenshot.  I use Skitch on OSX and just hit Print Screen on my Windows machine.  Then drop or paste that screenshot onto Nudger.  It’ll load up the image.  From there you can click & drag to define an area to nudge.  Then move it around with the handles that appear.  You’ll get feedback while you do it.

Here’s some screenshots (I’m working with a screenshot of the Flash CS4 splash screen here)

Step 1, right after pasting it.

Next, I select an area of the image with the mouse.

And finally I move it around.

The grid below the selection tells me the original location/size of the selection, the new location/size, and how much that differs from the original.  If this were an app I was working on, I’d know I need to bump those objects over by 221 pixels and down 5.

Of course you can make multiple selections and move lots of stuff around.

Why I like my proposed catalyst workflow

I’ve been an advocate of compiling from Catalyst to a swc in a two previous blog posts.  (A Flash Catalyst / Builder workflow method , Compiling FXP->SWC, a Catalyst workflow) I’m hoping to explain why I prefer that workflow here.  With big pretty pictures!

First, let us look at the catalyst workflow that’s been all the rage in the demos online that introduce catalyst (like this one).  Refer to the diagram below.

workflow1

Pros:

  • Super simple

Cons:

  • Limited to one designer and one developer
  • Limited to a single catalyst project
  • Developer can’t start until designer is finished
  • Once the designer has handed off the file, they can’t make edits.

If your software development process can handle those cons, this “super simple” option will rock for you.  But for anything beyond the most trivial of projects, those restrictions will be a deal breaker.  I consider this workflow similar to editing Actionscript in keyframes on the timeline in Flash.  It works, it’s simple, sometimes it might be the right way of doing things, but most of the time it’s like shooting yourself in the foot.

Something that hasn’t been as widely discussed, but that is still part of the official offering from Adobe goes something like this diagram:

workflow2

In this scenario, the developer creates a plain old Flash Builder project.  While he’s doing that, the designer creates a .FXPL file.  The developer takes that .FXPL and imports it as a Flex Library project, which he then references from his main project.  (Just import the .fxpl like a .fxp, the correct type of project is auto-created) Later, the designer can make changes in Catalyst.  Then the designer exports a new .FXPL file and the developer can re-import it (re-import steps below).

Optionally, the developer can move the classes into a package structure inside Flash Builder.  If there will be more than a single .fxpl imported, this is required since there will be name conflicts.  Currently, the refactor in Flash Builder doesn’t work 100% for this as the skin references aren’t updated, hopefully that’s just a beta-bug and will be fixed.

This is a huge improvement over the previous workflow and will probably work out great for most people.

Pros:

  • Developer and Designer time can overlap
  • You can have multiple designers and developers (by repeating that middle bit in the diagram
  • Can use a package structure
  • An “official” Adobe method

Cons:

  • Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project.
  • Every time a new .FXPL comes out, the developer must (I bet some of this could be automated!):
    1. Delete the current Flex Library project
    2. Import the new .FXPL
    3. Modify the main project to reference this newly imported project
    4. Move the classes in the Flex Library project into a new package structure
    5. Rebuild the swc
    6. Rebuild the app
  • Does not retain the Main class from catalyst, so all work must be done in sub-components

That’s doing a lot better in the scalability department.  It’s doing a bit worse in the complexity department.

What if we could automate some of the process of turning a .FXPL into a .swc?  Or even better, what if we could turn a .FXP into a .swc?  Then we’d have something that looks very similar to the previous workflow, but with one important difference:

workflow3

Pros:

  • Developer and Designer time can overlap
  • You can have multiple designers and developers
  • The script automatically converts the Main catalyst component from an Application object to a Group object so you can use it in your project.  (Coming Soon!  The next version of my script will)
  • Automatically uses a package structure

Cons:

  • Developer is not allowed to edit the Flex Library project that is imported, he can only use classes/assets from it in his main project. (But he only ever sees a swc now, so no worries)
  • Every time a new .FXP comes out, the developer must somehow get the new .swc (more on this below)
  • Requires a script to run (requiring whatever environment that script was written in)

That may seem like a fairly minor difference, but imagine how much better it scales.

Instead of a single developer and a single designer, picture a whole team of them.  If every developer needs to go modify their workspace every time any designer makes a new .FXPL, they’ll end up spending too much of their time just managing their build environment.  The more people you add, the worse it gets.

If that script can be run through a command line script, it can be automated.

Most teams that consisting of more than a couple people use a version control system.  That system can be used to distribute .swcs that are generated from the catalyst projects.  Many version control systems have hooks integrated into them so they run a script whenever a certain file or directory is modified.  If yours doesn’t have than a simple scheduled job could do it.  This can simplify the process even further to:

  1. Designer checks .FXP into version control
  2. Script runs, automatically generating the .swc
  3. Developers sync up, getting the new .swc

That means, once it’s set up there is no additional work that needs to be done.  The designer works in his tool.  The developer works in his.  Assets are magically propogated.

If you don’t use a version control system, scheduled jobs and a shared network folder could do the same thing.

This solves the scalability problem.

workflow4

All that is good-and-well, but that script to generate the .swcs must be awfully hard to do, right? Wrong. It was easy. It’s done. Go give it a try.

Blog post describing the script.
Download: fxp2swc.rb

Any windows based Ruby developers want to take a crack at updating the script to work correctly on windows?