Disqus - Latest Comments for Cyberfox

Re: Comments

Morgan — Fri, 23 Apr 2021 01:41:11 -0000

Yes; the innumeracy struck me at the very first step of reading this. I don't dismiss the idea of coding every day, and for the brief periods of time when life doesn't intervene, I've loved doing it myself because I love programming. But...it's not magic. No, you're not going to be '37 times better', but 1.44 times better is still really good over the course of a year.

That said, your ability as a software engineer is not about how many algorithmic problems you can solve, no matter what leetcode and the like tell you. It's about holding the entirety of a complex system in your mind, abstracting reasonably from experience the parts you don't know in detail, and reasoning about how it will operate when you make _this_ change, and how you'll know if you're right, and how to weigh the options, none of which are 'the best answer'.

Your ability to build systems comes from...trying to build or understand whole systems, not solving small problems. Nobody hires programmers to write quicksort, they hire programmers to solve complicated, no-right-answer problems...maybe USING quicksort...when necessary. :)

So if you want to program every day...just...do it. Don't solve small algorithms. Work on a big project. Write something that scratches an itch for yourself, that is meaningful to YOU, and that solves not just one algorithmic or data structure piece, but the whole thing...from UI to business logic to database access, and then, once it works for you (and not before!) pretend that you need it to scale, and think about how you'd do that, and build it. Small 'solve in a day' problems lead to small thinking. Think big.

Re: Google Home review: Three weeks with a voice assistant that's actually worth talking to

Morgan — Mon, 28 Nov 2016 20:50:51 -0000

I got an Amazon Echo for 2nd place in a work competition, and within a day I'd written a new 'Skill' for it in Python that scraped a popular website and gave me a summary of useful information from it. That's pretty amazing, and I very much hope that Google builds that same kind of ecosystem around their product.

Right now, I want a Google Home device just for the capability of asking it searchable questions, and getting The Answer, rather than Alexa's 'I'm not sure I understood the question.'

The flip side is that Alexa's music selection (with Unlimited Music) is pretty amazing. So it looks like I'll have to have both of them for a while...if I get a Google Home for Christmas. :)

Re: The Smatest Cities In North America: Methodology

Morgan — Fri, 15 Nov 2013 12:27:32 -0000

You...ummm...might want to fix the typo in the title. :)

Re: How to Evaluate a (paid) iPhone App Idea

Morgan — Thu, 16 Feb 2012 14:43:47 -0000

This is awesome research; now you've got me thinking about releasing my app for free and including various quantities of 'sniping points' that you can buy, and then doing the snipes on my own server... :)

Those numbers are crazy big, though. For a one or two developer team, $25K/mo. is a great foundation at the 600th highest grossing. How far out does that curve go? What's an app that averages (in a month) being the 1000th highest grossing paid app make per month? 2000th? Is there any way to know?

Or, to be more specific, it seems you have a mathematical model based on the data points you've collected. Can you estimate at what 'nth highest grossing' level it crosses some arbitrary value, like the $10K/mo. number?

Re: Fun with Ruby: Get All Nancy Drew on Chrome - Intridea Blog

Morgan — Wed, 02 Feb 2011 18:41:03 -0000

Cool!

I've tried doing the same thing to Mac applications' Core Data files (which are also really just SQLite databases, but with some undocumented extra mappings, and everything prefixed with 'Z') without anywhere near as much success.

I'd love to see AR used more outside of Rails; it's a really useful framework. Painfully huge (~9MB with dependencies!) for desktop/downloadable apps, but still really useful.

Re: Rethinking “F@#$ You Money”

Morgan — Mon, 02 Aug 2010 19:17:30 -0000

If you take 2 mil, and ladder it into 5 five-year CD's earning 2.5%, you're netting about $52.5K/year without touching your principal, and that's in this market. Not great, but not bad, and leaves your money relatively dry, so you can move it around if the markets get better, or other opportunities arise.

If you net out $4M, then you're looking at a baseline of $106K/year income using laddering without touching principal, from what is possibly the most conservative investment strategy possible. :) At that point, you can blow 5 years working on your s00pr-c-krit algorithm for flurgling plurbuses, never see a dime in income because there are only 4 plurbuses in the world, and just not worry. Need more? Dip into principal. Things get better in the market? Move some cash into the market, and pick up a few years of 8% average returns.

I'm not disagreeing that it's a great approach to become famous and live off of that, but there really are only so many Linus Torvalds or DHH's out there (to use examples from my field).

The other problem I have with 'F-You Influence' is that you have to keep selling it. Go a few years without selling yourself, and your 'funds' (that is, credibility) dries up.

That's not retirement, that's a permanent sales job.

I doubt I'll ever _actually_ retire; I love computers and programming too much, and just doing cool stuff throws off "gettin' paid" opportunities regularly, but I do imagine a time when I stop having the NEED to get paid.

Re: How to use Amazon’s S3 web service for Scaling Image Hosting

Morgan — Wed, 14 Jul 2010 21:57:06 -0000

Greetings,
I talked about something like this on the S3 forums a while ago; we used S3 as the image store, but what we did was pre-resize images to a set of sizes. The user uploaded directly to S3 (jquery forms rock!), and was redirected to our site on completion. We triggered a background job off of that to pull down the image, resize it, and push the resized images back up.

The truth is we didn't need it to be an arbitrary number of different sizes; we knew what our thumbnail sizes would be in advance, and S3 storage is sufficiently cheap that we didn't think twice about pushing up shrunken versions. We also kept the originals, but in 'private' storage, so only our app could access them, in case we needed to re-resize later.

The thumbnails (shrunken versions) we marked as public on S3, so we could serve them directly from Amazon, and never needed to touch our servers. Finish up with a few rotatable CNAMEs to point to our S3 bucket (like your asset hosts) and image hosting upload or view never touches our app server bandwidth, and is fast for the end user.

It's a fun problem, and your solution makes sense for your constraints.

-- Morgan

Re: The future of shoulda

Morgan — Wed, 16 Jun 2010 01:36:24 -0000

Greetings,
Well...crud.

I really liked shoulda's context/setup/should framework, disliked the macros, and am not an rspec fan, so I'd be the target audience for the context framework...but you're saying you won't be doing ongoing development on it, once you split it out.

That'll make for a low chance of convincing companies to use it, unfortunately. (And yes, in three companies so far, I've been the one introducing testing frameworks, and it's been Shoulda each time.)

I understand why you're doing it; your direction has changed, and it's not the way you do development anymore. It's still kind of sad, though. Shoulda was the clean, simple alternative to rspec, with no compatibility issues, and all the real advantages. I'll miss it being under active development.

Best of luck,

-- Morgan

Re: New things, Next Steps

Morgan — Sat, 05 Jun 2010 19:39:07 -0000

Greetings,
Looking at Feedjit, I'd say Stumble-Upon, essentially. 'Folks who visited the same pages as you also visited 'X', where X is selected via a formula that tries to avoid picking the broad-appeal sites. (I think Bayesian probability has some of the appropriate characteristics.)

Didn't you write something like the Feedjit widget in Flash at Jobster? :)

In terms of how you make money with it...gah. Allow ads and profit-share with the blogs? (I dislike the idea some...I prefer to sell features over ads.) Sell placement in the 'stumble-upon' feature? Offer logs to premium (aka paid) users? (I.e. they don't just see the 'live' feed, but can peruse N days back?) Sell demographic analyses?

Especially for Feedjit (but not clearly money-making), find and profile 'movers and shakers', the people who consistently view popular blog entries _before_ they become popular (i.e. traffic bumps). Those users are either influencers or coolhunters, and knowing more about them is valuable.

-- Morgan

Re: Guide to Evaluating Startup Ideas

Morgan — Thu, 27 May 2010 16:02:55 -0000

As a early-stage startup 'joiner' so far (as opposed to founder) one of the best sniff tests I've found is whether it's something you yourself use or need.

The two companies I was with when they went wildly successfully public were both products that I used already before joining. Using a different product in the same space is probably okay, as is personally feeling a deep need for the product, if there isn't anything else like it.

There's certainly a place for building products that address pains you don't personally feel, but you won't be as good at gauging the pain relief. That's why it's a high value item for me.

But your #1 is definitely the most killer point.

Re: JbidWatcher...Has it Really Come to This?

Morgan — Wed, 17 Jun 2009 07:27:34 -0000

Greetings,

Geez, no pressure... :) I hope JBidwatcher works well for you also. eBay made some changes recently, and I'm working on fixing them. In the mean time the things I'd watch out for are multi-item fixed price listings, sometimes losing seller information (name, feedback, etc.), and multisnipes are being trouble for some users.

Doesn't sound like any of that would affect what you're doing, though.

Best of luck with your auctions!

-- Morgan Schweers

Re: The Power Of Passed Links

Morgan — Fri, 17 Apr 2009 20:31:23 -0000

Greetings,

I figure this is mostly a call for datapoints; I don't know if this is helpful, but here's mine.

My 'conversion' is a download of my free application; pretty trivial, but it works for me. I normally get paid in egoboo, but this year I was unemployed and my (wonderful!) users ended up paying my mortgage payment. Twice. Since my scenario is very different, the behavior of my users may also be very different.

Organic search nets me a 39.3% 'conversion' rate, direct traffic nets 34.33%, and referral (the link posted on someone's page) is 30.23%. (Google Analytics | Traffic Sources | All Traffic Sources, Goal Conversion tab, show: Medium). Twitter.com shows up under referrals, and has a sub-10% conversion rate, Facebook shows up under referrals and has a sub-10% conversion rate. Traffic from both are so low as to be statistically meaningless though. That may be because my software doesn't appeal in a way that it gets shared on those sites often.

I don't have a presence on Facebook. I have a presence on Twitter, but I don't promote via twitter. Other folks do promote it, though; I see my application show up on search relatively regularly. My site has a PR (according to online tools) of 5.

I hope that info helps!

Purely as an opinion, I'd argue it's a heck of a lot better to encourage folks to blog about your software (or site?) with a positive link over passing the link to a subset of friends. It's a matter of permanence and audience. The link tells the search engines you're a useful resource. Even if nobody but the search engine reads that link, it informs everyone who searches on that engine in the future. The incremental value of that over time is much better than a temporary personal referral that is quickly forgotten. This is worse under Facebook and email, which act as walled gardens, and so passed links are lost to the search engines.

Now I don't make a mainstream (read: very popular) app, or run a mainstream site, so I don't know how well this scales to folks who are talked about all the time. It's just opinion. It's also not an 'or' world; both types of links coexist, and folks who blog about something are also likely to recommend it person-to-person.

-- Morgan Schweers, CyberFOX!

Re: Francis Hwang: On fixtures and first-time testers

Morgan — Tue, 10 Feb 2009 15:57:56 -0000

Greetings,
Yes, we dealt with multiple contexts by having different sets of data. The key is consistent fixture naming; that lets you go right to the data. I'll agree that it was much harder before the 'foxy fixtures' change, when you had to refer to fixtures by id. Now though, a bit of thought when naming the fixtures, so you have a 'scenario' that's being identified, makes it much easier across the board.

One key for testing is reproducibility; I need to know that my data setup isn't doing any even mildly complex logic, and that when a piece of test data causes a failure that I can instantly identify which piece of test data it was.

I commented on the .new instead of .create because it's exactly that kind of simple, honest mistake that makes Ruby-created data sets require debugging, and fixture data just...not.

That said though, there's a interim period where folks have probably been creating fixtures without a consistent approach to scenario naming, and they find them really frustrating because they're mentally juggling random names like 'quentin' (wait, is he the pending user, or the old-style-password user?), and feel that the bathwater should be ejected, without de-babying first.

If you look around, the fixture-replacement stuff will probably look really attractive at that point. They'll probably help. A relatively consistent approach to naming fixtures after the scenario's they're being used for would help at that point, also. In fact, almost anything will help, because you've started to actually think about the problem, and if you're paying attention to the problem, it'll usually get better.

I admit, though, even I don't always start out with consistent naming, but when a project gets to a size where I have to spend a moment thinking, 'Wait, what's that fixture for this scenario again?', I know my reason for using them has changed from 'get data into the db quickly', to 'be able to find what data caused a test failure', and I go and clean up the naming. Once it's cleaned up, it's easy to keep following that path.

-- Morgan

Re: Francis Hwang: On fixtures and first-time testers

Morgan — Mon, 09 Feb 2009 18:57:05 -0000

Greetings,
I've worked on a pretty large site which was relatively complex, and we used fixtures exclusively for test data.

You don't have to debug fixtures. If you're curious what the data that was being used is, you just go to the data. That's so important, that I need to clarify. You don't have to debug fixtures to figure out what data is being used in a particular test failure.

Every time I see someone trying to build test data in Ruby they're doing loops over data, creating entries on the fly, and generally creating a maintenance nightmare that obfuscates the source of their data. Not to mention the slowdown, compared to just using fixtures.

Now, how is

david: login: david

complex? (Outside of the formatting eating my spaces...) That's what the fixture should look like. You really don't need to use id's anymore.

By the way, your example doesn't leave it in the database, and doesn't help when you have referenced objects. So let's say you have a user, who has posts, and friends...are you going to recreate all that information for every test that goes through a path that uses that information? If so, then you've created a whole 'nother library to create your data objects, and that library will need debugging...and boy, debugging the library that creates data for your tests to use, so you can test your application is solidly in the 'how smooth, Mr. Yak?' category to me.

Fixtures (in their current incarnation) make relationships incredibly easy, and you always know that (1) the data is there, and (2) what the data is.

I really don't get the hatred for fixtures. I've worked on some complex Rails apps, and I've never seen a problem that required converting wholesale to a different method of test data creation. There are instances where you may want to create specific blocks of data programmatically, but fixtures are so incredibly useful (and performant) that you want to use them for most test data, especially as your tests get into the thousands-count.

The end result of this, is that I strongly disagree with the assertion that fixtures are a bad default for Rails.

-- Morgan

Re: Git Timecard

Morgan — Fri, 23 Jan 2009 08:43:56 -0000

Greetings,

I was curious, and thus inspired, to try this myself. As dustin said, the recipe was pretty straightforward. Understanding that git log --pretty=format:%at was unixtime was the key, and everything fell out from there. (Well, after I'd figured out the fiddly bits of the Google Charts API, and fixed a bug in the gchart gem...)

Check out http://github.com/cyberfox/... (which requires the cyberfox-gchart fork of the gchart gem, btw) for a Ruby example of how to do it.

-- Morgan Schweers, CyberFOX!

Re: A Newbie’s Guide to Startup Compensation (or “Stock Options will Make Me Rich!”)

Morgan — Fri, 29 Aug 2008 21:31:09 -0000

Greetings,
Hey back...

You're right, in a lot of ways, that the current boomlet is going to be a little lower key, but one of the things I notice from those lists is that the companies who actually have a product/service they sell (as opposed to media outlets, where they only make money by advertising) are consistently going for more. 'Profitable' isn't a dirty word anymore. :)

As for the IPO's not having the run-up, I completely ignored the 'opened at $20, jumped to $200' type of IPO. Opening at $12, and jumping to $20 is _awesome_, and is what made me a paper millionaire back in 1992. (Being profitable for 2 years before going public, and an obscene profit margin helped.)

As for your article, you also should note the differences between Non-Qualified options and Incentive Stock Options, as they have very different tax implications.

-- Morgan

Re: A Newbie’s Guide to Startup Compensation (or “Stock Options will Make Me Rich!”)

Morgan — Fri, 29 Aug 2008 18:28:13 -0000

Greetings,
To throw in my voice, @michah: that's a good point (there's actually almost always an exercise-by date even if you _don't_ leave the company), and it's also worth talking about the different tax consequences of early exercise, same-day exercise and sell, and exercise and hold for > 1yr.

@Danielle, you can basically calculate your percentage of potential ownership based on the number of shares granted divided by the number of shares outstanding. It's hard to get that number out of most private companies before (and sometimes after) joining them.

Dilution by subsequent rounds of funding is often bad. I had a 200:1 reverse stock split happen on one company I'd worked for, which meant I got 1 share for every 200 I previously had, and then they added new shares and sold them to raise more money. There's also squirrely issues with preferred stock.

The basic answer (in my experience) has been that the more rounds of funding, the less likely a liquidity event is, so make sure you're comfortable with your salary _first_. Rare is the company who actually 'just needs a little bridge loan to get to profitability'.

-- Morgan

Re: A Newbie’s Guide to Startup Compensation (or “Stock Options will Make Me Rich!”)

Morgan — Fri, 29 Aug 2008 18:18:51 -0000

Greetings,
Having been through two very successful IPO events a decade apart (MCAF in 1992 and PYPL in 2002), I can tell you that it's definitely doable to get a million dollar event (on paper, at least) for a non-founder employee. Of course you have to be smart about the money if you're going to keep it. :)

I've also been through two companies where I had/have options, but those options are, and are likely to continue to be, worthless, and two where I left before my initial shelf vested. Still, out of 6 startups, all of which were fun at the time, two major successes is better than most people get.

The real idea (to me) is that you can do work you are excited about doing, in an environment where _your_ decisions affect the success of the company, get paid for it, and have a non-zero chance of getting a particularly excellent pay-out if you make the right decisions and build something people really care about.

Sure, as an employee (instead of founder) there are factors out of your control, but in a startup you have much more control than an employee in an established company, along with more risk and commensurately more potential reward.

In my experience few people optimize their salary quite to the extent that they can reasonably say, 'Okay, I'm taking a $10K pay cut from what I could be making, in exchange for an extra 0.X% of the company'. Most folks in the successful startups I've been part of just looked at their base salary (and typical benefits), decided if they could live with that, and ignored the options as being merely a potential bonus.

Actually with the first company I went public with, employees didn't even have 'stock options' until we began the process of going public. Typically employee stock options weren't something that line employees got, back then.

People often call it the 'stock option lottery', but I can't think of any lotteries that pay you to participate, and you can improve your chances of winning by doing great work.

-- Morgan

Re: 2904 S Washington St - Applying the "Life is too short to deal with orifices" principle

Morgan — Tue, 25 Mar 2008 16:11:06 -0000

Greetings,
A top guideline of my feed list... Is the person DOING something, or are they just talking about the people who are DOING things.

It eliminated a lot of my guilty pleasures like Scoble, but it helped both my blood pressure and my motivation.

-- Morgan