Some details: February: worked on Dash 2.0 May: mostly played Hearthstone :( August: 3-week holiday September-October: worked on Dash for iOS November: 2-week holiday December: mostly played Hearthstone :(

Labels: business, hats of money, indie

13. I would tell you a UDP joke, but you might not get it.

This morning, a number of developers signed in to Apple's iTunes Connect service only to be greeted by a list of apps that didn't belong to them. TechCrunch has a good roundup of tweets from affected developers—it seems that whenever developers signed in with their credentials, they were being granted access to other developers' accounts at random.

Labels: apple fail

I wanted to see if JSHint had a provision for checking imported packages for property names in a file it was, um, "hint"ing, and ran into a link to the, "Why I forked JSLint" post (which was down -- domain now points to github? -- but lives at archive.org) again. The post is interesting. The representative example given to fork JSLint is a horrible one, imo. Kovalyov argues that he should be able to put a var before a iterator variable, like this...

for ( var name in obj ) { ...

That's really not a good reason to leave JSLint. Forcing you to acknowledge variable hoisting doesn't seem that objectionable. There are other things that it forces you to do that I don't see as much wisdom in, but this really isn't one of them. And that his snippet has "Example taken from jQuery 1.4.2 source" as if that made it automatically something worth emulating also gnaws at my craw a bit.

But the post's epigraph from Crockford does resonate:

Your sadly pathetic bleatings are harshing my mellow. —Douglas Crockford.

Wow. Reminds me of the link I use in my StackOverflow profile to undercut where I quote, "You should take JSLint's advice," a bit. The guy's a great coder, and I enjoy his very strict approach to JavaScript 99.44% of the time, but Kovalyov is right: Crockford's social skills (and, from what I've seen, hubris) are awful.

But again, bad social skills don't make the tool just as toxic. Kovalyov links to Brenan Eich, "creator of JavaScript", where Eich says, "JS Lint can suck it" That's said, sure (Eich is using automatic semicolon insertion, though he's doing it to make his code look like CoffeeScript, so Kovalyov has already taken the quote well out of context), but there's an interesting counterpoint Kovalyov misses in that same blog post from Eich:

Here's my pitch: committees do not design well, period. Given a solid design, a committee with fundamental disagreements can stall or eviscerate that design out of conservatism or just nay-saying, until the proposal is hardly worth the trouble. At best, the language grows larger more quickly, with conservative add-ons instead of holistic rethinkings.

What I like most about JSLint is that I know I'm getting similar code across the board. JSLint honestly enforces well-considered conventions. When Kovalyov says, "It is quickly transforming from a tool that helps developers to prevent bugs to a tool that makes sure you write your code like Douglas Crockford," my reply would be, "And you think your committee is going to do better?"

So many questions about JSLint on StackOverflow get answered with, "You should use JSHint." But if we all use JSHint to turn off whatever bugs us, as we'd do if we followed that advice each time, what do we leave turned on? Just the things that aren't troublesome? Isn't our code getting lint-i-er each time? Show me an example of where what Crockford requires from you is wrong -- not just annoying, but undeniably worse than an alternative. I don't think it exists, yet.

Isn't the point of a linter to challenge us all to write better code?

Labels: coding, culture, JSLint, style

I don't hate Thunderbird, but I can see why folks aren't drawn to it. It's very Netscape 3.0-ish and its interface is, at times, horribly unintuitive. It's got *everything*, but everything isn't particularly accessible. I can't imagine if I was coming into Thunderbird cold and hadn't used since, well, early Netscape.

Here's an example.

If you want to set the display font for "plain text" emails in Thunderbird, you have to go to Tools >>> Options, Display, Formatting, click the Advanced button, then click the Monospace drop-down and select a font and size. But I kept getting what many of what were obviously plain text emails in a much larger font than what I'd set.

Turns out that the "Fonts for [Western]" drop-down at the top of the Advanced fonts interface only works for ASCII (I'm assuming) emails. If you want plain text emails in UTF-8 to have a different font than the default as well, you have to choose "Fonts for [Unicode]" from that drop-down. This bugzilla thread helped. Not sure why there's a distinction. Perhaps other languages have different fonts for different 7-bit encodings? But shouldn't there just be a concept of a "default" display?

So right. Guess I should've figured that out. /sigh Why you can't just right-click the message you're looking at and set your font (for the whole app) there, I don't know.

Labels: encoding, thunderbird

Today's headline is essentially the flip-side of a a post by Release Notes' Charles Perry that Marco shared yesterday. The post's conclusions on app revenue would make that Jump to Conclusions guy from Office Space proud:

In fact all apps above number 3,175 on the U.S. Top Grossing list produce enough revenue to at least make its developer [<<< sic!!] the United States household median income for 2014 ($53,891). And this is just for a single app.

Let's pretend his calculations are on the money. I don't know if they are or not. He mentions "Pareto distribution" with the requisite link to wikipedia, and, well, his n equals 1, so it seems legit. ;^)

It seems that even with the revenue curve tilted so heavily towards the big hits, the shape of the App Store still allows room for sustainable businesses to develop in the long tail. It seems that developers who work hard, mind the details, and treat their business like a business have a real chance of making it.

Really? That's Perry's take-home? "A real chance" as in, "if you don't buy a lottery ticket, you don't have a real chance to win"? I really enjoy Perry's podcast, but this post is horribly rose-colored.

Take another look. If your app is top 3175 for an entire year (which it very likely won't be, okay? Check out Exhibit Jared Sinclair), you'll have median income -- about what a reasonably experienced teacher makes, afaict. You know, those folks we always say are underpaid, largely because they deal with our brats day-in and day-out, but let's face it, unlike that of most key-masher engineers, it's not an unseemly, brat-resisting, over-the-top salary.

Again, that's iff your app doesn't fall out of the top 3175 for an entire year. Essentially Perry's pie-ish in the sky-ish numbers don't factor in app ranking churn. What you really need to know is how long it takes for an app like yours to drop from, say, 500 to 4000. I bet it's not very long.

Look, let's put this another way. Let's say that app ranking churn isn't nearly as volatile as I'm betting it is (even though, let's face it, I'm not wrong). If we define median income as our goal, if these numbers are accurate, only 3175 developers worldwide made median income or above on the app store for however long these revenue numbers are accurate. And that's only if each of those apps was written by a one-person shop! Perry does put in a caveat, implicitly asking, "What if you had two apps in there?!" Are we assuming they're both in the top 3175 for a year? Really? Guess what that means for the number of viable professional indie app developers?

And look, let's assume he does has access to non-median revenue fail apps. What did they make? Do they fit the curve and his predictions? What does our ranking over time look like? How long does an app sustain a "median wage" ranking if it breaks into the top 3175?

Each successful app on the way down but still in the rankings is another spot you can't get on your way up. I'd almost rather grow hand-cultivated wheat. Less risk.

These numbers are awful. That's not even a large company's worth of people. Ouch.

Good luck, everyone, in this year's hunger games. Or Thunderdome, or whatever your version of "scarce resources favor predators" metaphor is.

Labels: app store econ, business, hats of money, indie, ios

1. Table stakes (do what everyone else does)
2. Killer feature
3. Lucky launch
4. Profit

I thought Manual was way too niche. How many people actually wanna set ISO on their smartphone? It never crossed my mind that it could exceed Everyday's launch. The launch went so unbelievably well. I was blown away. People were tweeting, the press was great, Apple featured it immediately. Shock and awe. I will toot my own horn and say that the video I made with Oliver helped a lot.
Manual was available for 100 days in 2014. Here’s my dinky:

95,621 total sales.
$123,413 USD total revenue (after Apple’s 30%, before taxes).
$91,773 USD in the first month.

Yeah it was [screwed] up. In terms of up-front expenses it was minimal, the investment is our time. I spent $1,500 on the website, video, sound design, domain, and stock photos. There are no substantial monthly expenses.

I submitted Manual a week before the iOS 8 release from Phoot Camp over shaky wifi. Including a fun last minute sprint to create new screenshot sizes for the iPhone 6 and plus. We got lucky and Apple approved Manual a few days later.

Labels: apps, indie, ios

Labels: usenet

Labels: digital, Randmo

public static string ToQuotedPrintable(this string self)
{
    byte[] bytes = System.Text.Encoding.UTF8.GetBytes(self);
    StringBuilder sbInner = new StringBuilder();
    StringBuilder sbOuter = new StringBuilder();

    foreach (byte byt in bytes)
    {
        int charLenQP = (byt >= 33 && byt <= 126 && byt != 61) ? 1 : 3;
        if (sbInner.Length + charLenQP > 75)
        {
            sbOuter.Append(sbInner + "=\r\n");
            sbInner = new StringBuilder();
        }

        if (1 == charLenQP)
        {
            sbInner.Append((char)byt);
        }
        else
        {
            sbInner.Append("=" + byt.ToString("X2"));
        }
    }
    sbOuter.Append(sbInner);
    return sbOuter.ToString();
}

Labels: c#, code, encoding, noteToSelf

His list of expenses leave out one really big thing: marketing. Through hard work and good fortune, Marco is a well-known figure among many of Overcast’s potential customers. This kind of exposure would be expensive for the average indie developer to replicate. For example, ongoing discussions of Overcast on the ATP podcast (before, during, and after the 1.0 launched [sic -mfn]) would have cost thousands of dollars — at least $3750 per episode. ... Promoted tweets that reach 78,000 interested Twitter followers wouldn’t be cheap, either, relative to $160K in revenue. Overcast also benefitted from numerous conversational mentions from friends of Marco’s like John Gruber, who carry a lot of weight behind their recommendations.

Perhaps Marco intentionally left out these things because he was worried about sounding like a jerk. I’m having a hard enough time writing this article as a third-party without sounding like a [punk], so I can appreciate the backlash he might endure if he mentioned them directly.

Labels: apps, business, indie, ios

If I'm reading this right, Apple had to pay damages because it had secure p2p video connections </ full stop>.

VirnetX had alleged that two of its patents - registered in 2002 and 2009 - had been infringed by Apple's iPhones, iPod Touches and iPads.

These referred to ways to establishing a secure communication link between different types of computers using a protocol referred to as TARP (Tunneled Agile Routing Protocol). ... "Apple says they don't infringe, but Apple developers testified that they didn't pay any attention to anyone's patents when developing their system," a lawyer for VirnetX was quoted as saying by the Bloomberg news agency.

from here:

The VirnetX patents cover the use of a domain-name service to set up virtual private networks, through which a website owner can interact with customers in a secure way or an employee can work at home and get access to a company's electronic files.

Look, if you can invent the same thing without having any idea the other existed, I'd say you haven't [in any society run by common sense] run afoul of a patent. And unless this predated Gnutella (it doesn't, I don't believe), you've got prior art, right?

Apparently some of the decision was "vacated", but I think we can agree the patent system isn't optimal. I hate that I can't even understand the argument after reading two articles. When the crux of the issue is this obfuscated, you're just playing what Gygax called (iirc) "semantic gymnastics" at this point.

Patents in software drive me crazy. Too much is painfully obvious. I understanding protecting something limited and genuinely new, but this is insane.

(sourced from reddit)

PS -- Manatees? Sauce:

Cartman is introduced to the Family Guy writing staff, who turn out to be a group of manatees. The staff, who live in a large tank, pick up "idea balls" from a large pile of them, each of which has a different noun, a verb or a pop culture reference written on it, and deliver them, five at a time, to a machine that then forms a Family Guy cutaway gag based on those ideas.

Labels: apple, hats of money, patents

$164,134 total revenue after Apple’s 30% but before any taxes or expenses.

For most people, the App Store won’t be a lottery windfall, but making a decent living is within reach for many.

It had a perfect launch that far exceeded my expectations — it was the best launch an indie developer could possibly hope for, with tons of great press, a mid-level App Store feature, and thousands of tweets on launch day.

Labels: app store econ, apps, business, indie, ios

Look Ma! More Perl!

;_; (aka QQ)

Again from Learn Perl in about 2 hours 30 minutes:

Unlike almost every other major programming language, Perl calls by reference. This means that the variables or values available inside the body of a subroutine are not copies of the originals. They are the originals.

You're killing me, Perl.

(Bee tea dub: Nice doc on perl command line options here -- -l is a nice alternative to say)

Padre fails

In the "won't behave" category, add still being unable to install Padre, the at least implicitly recommended IDE for Perl, with cpanm or cpan. And I'm not the only person. What a versioning mess.

Loops are fun!

And finally, this jive on loops is more note-to-self, but isn't especially intuitive either:

Basic C-style for loops are available too. Notice how we put a my inside the for statement, declaring $i only for the scope of the loop:

for(my $i = 0; $i < scalar @array; $i++) {
    print $i, ": ", $array[$i];
}
# $i has ceased to exist here, which is much tidier.

This kind of for loop is considered old-fashioned and should be avoided where possible. Native iteration over a list is much nicer. Note: unlike PHP, the for and foreach keywords are synonyms. Just use whatever looks most readable:

foreach my $string ( @array ) {
    print $string;
}

... and it's intuitive, too!

Remembering that $#array gets you the array's length (argh. Of course)...

If you do need the indices, the range operator .. creates an anonymous list of integers:

foreach my $i ( 0 .. $#array ) {
    print $i, ": ", $array[$i];
}

You can't iterate over a hash. However, you can iterate over its keys. Use the keys built-in function to retrieve an array containing all the keys of a hash. Then use the foreach approach that we used for arrays:

foreach my $key (keys %scientists) {
    print $key, ": ", $scientists{$key};
}

Since a hash has no underlying order, the keys may be returned in any order. Use the sort built-in function to sort the array of keys alphabetically beforehand:

foreach my $key (sort keys %scientists) {
    print $key, ": ", $scientists{$key};
}

If you don't provide an explicit iterator, Perl uses a default iterator, $_. $_ is the first and friendliest of the built-in variables:

foreach ( @array ) {
    print $_;
}

Packages are also fun!!!

Packages and modules are two completely separate and distinct features of the Perl programming language. The fact that they both use the same double colon delimiter is a huge red herring. It is possible to switch packages multiple times over the course of a script or module, and it is possible to use the same package declaration in multiple locations in multiple files.

You can see where this is going, right? I was already loling in my head at how convoluted the two concepts could get by this point. -mfn

Calling require Foo::Bar does not look for and load a file with a package Foo::Bar declaration somewhere inside it, nor does it necessarily load subroutines in the Foo::Bar namespace. Calling require Foo::Bar merely loads a file called Foo/Bar.pm, which need not have any kind of package declaration inside it at all, and in fact might declare package Baz::Qux and other nonsense inside it for all you know.

Likewise, a subroutine call Baz::Qux::processThis() need not necessarily have been declared inside a file named Baz/Qux.pm. It could have been declared literally anywhere. This next bit at the close of the packages/modules section is probably best considered a universally applicable tenet of programming:

However, it is important that you do not take [any convention or best practice] for granted, because one day you will meet code produced by a madman.

I don't think I'd ever recommend Perl for someone's first programming language. Probably not even their second (I think I'd recommend 6502 assembler (because you should know, in at least a simplest case, how the things work) and then C# at this point).

VIm is not the IDE you were looking for

And here's a VIm related issue...

I'm trying to trick to run :!perl % to run what I'm editing in a shell, but right now VIm is opening PowerShell, which is executing my PowerShell profile and dropping me into the directory I have PowerShell navigate to by default. When it's there, it can't find the file in %, of course.

I tried Open Perl IDE, which was rough running, and there's some sentiment that it's not working well with recent versions of Windows.

Seems it would be insanely easy (all things considered) to write a Perl IDE for Windows (and Open Perl IDE had 131 downloads from SourceForge (that we know is evil now) this week) since Perl provides its own debugger for goodness' sake, but it doesn't appear to have been done.

WHAT A PAIN.

Others feel your pain.

from here, and the first quote is from the page's author:

2014-09-08 09:20:04 by Sam:

PHP is a minor evil perpetrated and created by incompetent amateurs, whereas Perl is a great and insidious evil perpetrated by skilled but perverted professionals.

... or, better yet...

2014-09-07 05:37:51 by David Mitchell:

Dear God. Not[e] to self: never use perl.

Labels: perl

Again from Learn Perl in about 2 hours 30 minutes:

Perl variables come in three types: scalars, arrays and hashes. Each type has its own sigil: $, @ and % respectively.

I started dropping which was which in my head trying to remember what the character was for grabbing a reference, and decided it was mnemonic time.

Taking a closer look, the mnemonic's already there, and is painfully obvious. For those even thicker than me (ha), they are...

• $ is for S is for Scalar.
• @ is for A is for Array
• % is for, well, I guess H, since it's Hash.

Okay, the "H" isn't quite as obvious as it could be (# would probably be more obvious, and then we could use // for comments, but I digress ;^D), but the first two are as obvious as they can get.

Duh.

And as for grabbing references, that's a backlash. Because why not, I guess.

A reference is created using a backslash.

my $colour = "Indigo";
my $scalarRef = \$colour;

Any time you would use the name of a variable, you can instead just put some braces in, and, within the braces, put a reference to a variable instead.

print $colour; # "Indigo"
print $scalarRef; # e.g. "SCALAR(0x182c180)"
print ${ $scalarRef }; # "Indigo"

As long as the result is not ambiguous, you can omit the braces too:

print $$scalarRef; # "Indigo"

or, for an array...

my @owners = @{ $ownersRef };

In other news, I was trying to install Padre with Strawberry Perl, and was following the apparently years old suggestions to the letter. After trying to cpanm Wx, however, I got this encouraging bit in a failed build log:

Test Summary Report
    t/04_userdata.t (Wstat: 0 Tests: 65 Failed: 0)
    TODO passed: 25, 33, 41, 57
    t/14_eh_die.t (Wstat: 0 Tests: 5 Failed: 0)
    Parse errors: Bad plan. You planned 6 tests but ran 5.
    Files=23, Tests=772, 444 wallclock secs ( 0.27 usr + 0.34 sys = 0.61 CPU)
    Result: FAIL

This sort of thing has apparently happened before and may be some sort of version conflict.

Idk, when I was using fink on OS X (I think brew is the more popular package manager for OS X now), I never hit this sort of issue, which was pretty impressive. You'd think Perl on Windows would be popular enough to be pretty painless. It's not.

Labels: noteToSelf, perl

Perl has no boolean data type. A scalar in an if statement evaluates to boolean "false" if and only if it is one of the following:

undef
number 0
string ""
string "0".

The Perl documentation repeatedly claims that functions return "true" or "false" values in certain situations. In practice, when a function is claimed to return "true" it usually returns 1, and when it is claimed to return false it usually returns the empty string, "".

I'd like to engage [mfn author] and have him work the actual deployment there. He can also help us troubleshoot scripting issues that arise when the scripts run and work directly with [Perl guy] here. How is [mfn author's] Perl scripting?

> How is his Perl scripting?

Unfortunately nonexistent.

Oh, I am sure you will be great at it. :)

Labels: perl

From this StackOverflow answer:

P.S. Unfortunately, it is not that easy to simulate break in ForEach-Object.

Argh. That's putting it mildly.

Here's some slightly amended code from the StackOverflow question to which the above quote is responding:

1..100 | ForEach-Object {
    if ($_ % 7 -ne 0 ) { continue; }
    Write-Host "$($_) is a multiple of 7"
}

ForEach (1..100 in $range){
    if ($_ % 7 -ne 0 ) { continue; }
    Write-Host "$($_) is a multiple of 7"
}

Guess which one works and which doesn't?

The crux seems to be that the ForEach loop, where ForEach leads the line, is a conventional loop, but the Foreach-Object that you so commonly see with the % shorthand, but also when ForEach is used ANYWHERE other than the start of a line is a "looping cmdlet" that's going to freight-train from the start to the finish of your range.

How complicated is this? Check this blog post (that I stole the phrase "looping cmdlet" from)...

First it is important to understand that foreach -ne foreach-object unless used in the pipeline.

(emphasis is mine)

ForEach should be ForEach, if you ask me, but luckily nobody did, as I think the point is that when you're mid-pipeline, there's no real way to refer to what came down from the pipeline into your command, afaik.

That is, this is meaningless...

1..100 | ForEach ($myInt in $PIPELINE_VALUE) { if ($myInt % 2) { $myInt } }

... because $PIPELINE_VALUE doesn't exist. Pipeline values are only implicitly sent along -- unless, of course, you're pulling them up as a parameter in a module or function. Creating a $PIPELINE_VALUE variable, though horribly useful for .NET-threaded heads like mine, would break [2] PowerShell's useful pipeline paradigm.

The limitation with the lack of break, of course, is that you can't do this...

1..100 | % { if ($_ % 2) { $_ }; if ($_ % 30) STOP_EVERYTHING!!!1! }

You're going to run through all 1 to 100, afaict. breaking here would drop the whole pipeline clanging on the floor. And that's my beef, I guess. Why not change the usage of break in this specific context? It seems to be the exception that would prove the [usefulness] of the [general] rule.

So to ForEach proper, you need a two-stepped process (or you have to use a Where-Object cleverly as described in the SO answers, above).

Fun. I should rename this blog "PowerShell Commando".

[2] Okay, literally that's wrong. It would "encourage breaking from PowerShell's pipeline paradigm for a more .NET-ish one".

Labels: powershell

Can you show the code that you are using? It sounds like you are using [pscustomobject] in V3+ which turns into the System.Collections.Hashtable object you are seeing in V2.

Labels: powershell

Coming from JavaScript, it feels like adding a function to a hashtable in PowerShell shouldn't be that complicated.

Took a bit of googling, but it's not. For PS 3+...

$h = @{ spam = "spiced"; ham = "green" };
$obj = [PSCustomObject]$h | 
Add-Member -MemberType ScriptMethod -Value { $this.spam } -Name foo -PassThru

Create hashtable. Cast to PSCustomObject (this is the same as saying New-Object psobject -Property $h, which I might end up preferring for backwards compat -- and for the consistency of using a cmdlet). Pipe to Add-Member where you add your .NET method. Profit.

You can kinda tell it's [C#-ish] .NET because you're into the this paradigm inside of the scriptblock.

Want a function with params? Can do.

$h = @{ spam = "spiced"; ham = "green" };
$obj = [PSCustomObject]$h | 
Add-Member -MemberType ScriptMethod -Value { $this.spam } -Name foo -PassThru | 
Add-Member -MemberType ScriptMethod -Value { 
    param( $first, $second) 
    "first is $first, second is $second" 
} -Name DoStuff -PassThru;

That adds two methods, the second with params.

Calling the function is also painfully .NET-ese, right back to the parens that your first few weeks of PowerShelling taught you to avoid (original, pre-fiddled sauce):

PS> $obj.foo()
spiced
PS> $obj.DoStuff("first", "second")
first is first, second is second

I really dislike how that paradigm shift (from PowerShell modules to unabashedly .NET functions) operates, but I guess the point is that a Verb-Description is never going to belong to an object. They are tied to no specific noun. Yet PowerShell still feels a little like a kludge that too often gives up and dumps its problems directly into .NET. That's good, since I'm a .NET programmer, but bad in that PowerShell feels imcomplete and kludgey, and its culture (I think even the new-as-of-PS 3 [PSCustomObject] cast is kludgey, and that's straight from the Scripting Guy as the preferred method of doing this) is wrapping itself around these sorts of kludges instead of pushing forward PS development and best practices.

Maybe dumping into .NET is good. Idk. But it's sure grafty, grafty like the Tree of 40 Fruit.

Thanks to these links:

• http://poshcode.org/3719
• http://blogs.technet.com/b/heyscriptingguy/archive/2013/11/07/a-powershell-object-lesson-part-3.aspx
• http://stackoverflow.com/questions/14835983/how-to-create-real-objects-with-behavior-methods-in-powershell/14836102#comment20794105_14836102

Labels: OO, powershell

Also missing are broadcast networks ABC, CBS, NBC, and Fox. According to Sling TV CEO Roger Lynch, that’s because most consumers are able to find programming from those networks elsewhere — like on Hulu, for instance.

Labels: business, DTV

What? You're trying to open an html file with Excel that you just made from scratch [with another app]? Why would you do that? Well, for one, this seems to be the preferred way to use PowerShell to make Excel files when you want to control colors and other UI-specific information along with data. It's kind of strange that, when one of PowerShell's most useful group of functions is centered around creating and manipulating CSV files, you wouldn't have similar modules for Excel, but fine (Scripting Guy says it's because of Excel's heavy use of COM [1]).

So you get a nice html template, you have PowerShell data-i-fy it all up, you go to Excel to open it, and then BAM.

"You are attempting to open a file type (Web Pages and Excel 2003 XML Spreadsheets) that has been blocked by your File Block settings in the Trust Center."

Wait, what? The Trust Center? I mean, I understand when I have to Unblock-File on ps files I've sourced from the Net, but an html file I created (yes, "all by myself") in SeaMonkey [sic]? RLY, Excel?

You can follow the instructions and wade into your Trust Center to say, "Forget it. I want Excel to open ANY html file, whether I created it or not, in spite of the fact that you could've just checked to see if I'd created it and only stopped me if things were much more suspicious." Or you can try to do that and find your company's IT dept has made it impossible to change your Trust Center settings even though you have admin access for nearly anything else.

Well, if you find you're in the second group (the one with not exactly consistently enforced IT security policies) there's a workaround: Put your html file that you want Excel to open in a "trusted location". Who knew? Good thing the bad guys will never learn where the locations are and exploit this extra trust.

Here's a list of Trusted Locations for Excel 2010 -- a list that will look like crud until I monospace it (sauce: [3]):

Default trusted locations                               | Folder desc    | Trusted subfolders
--------------------------------------------------------+----------------+-------------------
Program Files\Microsoft Office\Templates                | App templates  | Allowed
Users\user_name\Appdata\Roaming\Microsoft\Templates     | User templates | Not allowed
Program Files\Microsoft Office\Office14\XLSTART         | Excel startup  | Allowed
Users\user_name\Appdata\Roaming\Microsoft\Excel\XLSTART | User startup   | Not allowed
Program Files\Microsoft Office\Office14\STARTUP         | Office startup | Allowed
Program Files\Microsoft Office\Office14\Library         | Add-ins        | Allowed

If you're not using 2010 or are looking for something similar for Word, etc, that info is here: http://support.microsoft.com/kb/922849

And voila. Look at that html file you painstakingly created and filled with data, now mangled beyond belief by that bastion of spreadsheet integrity, Excel! You're welcome. ;^)

[1] http://blogs.technet.com/b/heyscriptingguy/archive/2014/01/10/powershell-and-excel-fast-safe-and-reliable.aspx [2] http://technet.microsoft.com/en-us/library/hh849924.aspx [3] http://technet.microsoft.com/en-us/library/cc179039(office.14).aspx

Labels: excel, powershell

So if I have an array of hashtables called $ahash, and each hashtable in $ahash has a property called `name`, I can just do this...

$sorted = $ahash | Sort-Object { $_.name };
$sorted | % { $_.name };

Voila.

Maybe that's in the help, but I didn't see it. There some script block stuff described under `-Property<Object[]>`, but that's specifically for the Property param, which isn't exactly what I think we want. Lots easier than writing an IComparer and .NETting around your elbow to get back to your nose. /shrug

(I don't know why the p tags are so goofy in this post.)

Labels: noteToSelf, powershell