Click here to show or hide the menubar.
Feed last built: 5/20/2015; 8:10:15 AM.

Scripting News

What would you do if you woke up one morning and there was no Internet?

I asked this question on Facebook and Twitter, and got a variety of answers.

I think there are two "correct" answers.

  1. Start a new Internet.

  2. Cry.

Most people say they would go do normal things that don't involve the Internet, but I think the world would take a long time to adjust. Many of us remember a world without the Internet, but we don't remember a world without the Internet that used to have the Internet.

A question that reveals the problem is to wonder what would happen if you woke up one morning and found there was no electricity. Not much would happen in the world as it's currently configured without electricity, even though there was a time when it worked fine without it.

I think the Internet is sufficiently integrated into our civilization at this point that if it were to be removed, it would be such an enormous shock to our economy that.. well, that's why #2 is also a correct answer.

I'd like to think we could quickly boot up a new net. That's more likely than rebooting electricity because a lot of people who built the initial Internet are still alive and would know how to layer things so it could come back pretty quickly. Assuming the electric grid isn't dependent on the Internet. Which is itself a good question.

Apple Watch liveblog notes

I got my Apple Watch last week, and I pretty much love it.

I started taking notes on my exploration on my liveblog, which was designed for cumulative projects like this one. I wanted to be sure readers of Scripting News know about this.

http://liveblog.co/users/davewiner/2015/05/13/appleWatchNotes.html

Your comments and suggestions are welcome.

Something doesn't smell right about the rush to "deprecate" HTTP

Google and Mozilla and others want force all non-HTTPS sites to become HTTPS.

And while the name HTTPS sounds a lot like HTTP, it's actually a lot more complex and fraught with problems. If what they want to do ever happens, much of the independent web will disappear.

  1. First, the problem as I understand it, is that some ISPs are gathering data about the content flowing through their routers, inserting ads and cookies and otherwise modifying content. I agree of course that this is a bad thing.

  2. Going to HTTPS does not get rid of all possible ways of snooping and modifying content. A toolbar, for example, hooking in after the content is decrypted, could change the content. Google tried to do this at one point in the evolution of the web. And even if you couldn't do it with a toolbar, Google and Mozilla both own popular browsers. They could modify content any time they want. HTTPS won't protect us against their snooping and interference. Why are we supposed to trust them more than an ISP? I don't actually trust them that much, btw.

  3. Key point: If you care about whether ISPs modify your content, you can move to HTTPS on your own. You don't need Mozilla or Google to force you to do it.

  4. It also depends on how much you care. Sure in a perfect world I'd want to stop all of it on all my content, but in that perfect world I would have infinite time to do all the work to convert all my websites. I don't have infinite time, and neither do you. I try to pick my battles more carefully. You can waste a lot of time doing something because it seems the right thing to do and end up accomplishing nothing.

  5. What I care about is that sufficiently motivated people will be able to find my archive in the future. I don't think the odds are actually very good, for a lot of reasons. This is just the newest.

  6. Given that a vast amount of content likely won't move, Google and Mozilla are contemplating far more vandalism to the web than any of the ISPs they're trying to short-circuit.

  7. Aren't there other less draconian methods to try first? How about making it illegal where it is not and working with government to enforce the laws? How about developing competition that doesn't do it, so everyone has a choice? That's the way Google is changing how ISPs work in the US. Why not elsewhere? How about developing a kind of encryption that does not require websites to do anything? I don't know if it's possible, but I haven't heard any discussion of that.

  8. Couldn't you use a VPN to tunnel through the nasty ISPs?

  9. This is why we need to overthrow the tech industry as a governing body. It's run by people who shoot first and ask questions later. This is an awful way to be having this discussion, after the decision is made, without any recourse? This is the best argument for taking this power away from the plutocrats in tech.

How to have a future

The journalism world is having a fit of depression today as they learn that their something they've actually known for years: their distribution system is owned by the tech industry.

There is a solution. Start rebuilding your distribution system around the Internet. Instead of broadcasting to an audience, feed a community back to itself. Be distributors. Understand that you are not making the news. Your job always has been distribution.

It's all about your rolodex

  1. Gather all the rolodexes in your organization and merge them into a database.

  2. Be sure you have a field in your database called "Feed" and in that field save the address of your source's RSS or Atom feed.

  3. Make a river out of those feeds. Start watching that river. Tell your sources about the river, give them the address. About five minutes after that you will be jumping up and down with excitement.

  4. Make it your home page.

That's it. You've now created a future. Live in it, and learn from it, and evolve accordingly. There are no parachutes, no single well-defined path all news orgs will go down. You have to make it up as you go.

However, until you get your river going, you will still be in the print era. Any effort you make there is wasted, it's not how news works today or in the future. We live in an era where sources have direct access to people who want the news. The sources are learning how to use that power. You have to find new relevance.

You can use River4

River4 is an open source aggregator written in JavaScript that does all that you need to get started. I wrote it, so you know it's good.

One more thing

If you're a journalism educator, please make sure every new journalist you graduate has the ability to run a server, install blogging and river software. People should not be scared of this technology. It's not hard, and is more immediately valuable than learning to "code" -- it should be a prerequisite.

Facebook's Instant Articles

A few items related to Facebook's Instant Articles announcement that came in the middle of the night.

  1. I was briefed on this project last summer.

  2. It got me interested in the Facebook API.

  3. People who use Facebook want this. How do I know? When I post full text of stories on FB they read it and comment. When I post a link to my blog post, they still comment, but very often without having read the piece. As a writer I can only take so much of this!

  4. The place to put this functionality is in the CMS or blogging tools. If I were FB, I would have gone to the toolmakers first. Made sure there was broad support. Why do they care so much about the big brands? Maybe there's something strategic about this. Do the big brands really move first, fast, with confidence and innovation? Or are they driven by fear of missing out? Which motivation creates better user experience? (In my experience love is where creativity comes from, not fear.)

  5. I was told last summer that they were building on RSS. Of course that's a good thing, if true. It means that the content could flow not just to Facebook, but anywhere that's prepared to receive it. This creates many interesting options. In this, Facebook is being a good corporate citizen and Friend to the Open Web (with the qualification that I don't know for sure if it is true).

  6. I have asked for access to the tech now that it's out, but got rejected!

  7. I hope they change their mind.

  8. Bloggers matter, imho as much as any professional reporter. I want parity for bloggers. In this way they are not being a friend of the open web.

  9. The NYT, National Geographic, Buzzfeed, et al, are right to publish their content to Facebook in full. It's one of the big places where people who read news congregate. But they should also quickly develop new channels that are not dependent on the tech industry.

  10. Journalism pundits will re-litigate the michegas over The Algorithm. The time to debate that was when it was new, five years ago. It's done now. The next thing is whether or not the news industry invests in its own future, or lets the tech industry continue to own it. The Algorithm wouldn't have mattered if journalism had done its job. I guess that's where my frustration comes from reading the hot angry frustrated powerless pieces by Jay Rosen, Zeynep Tufekci and Emily Bell. Where were you when this was news? And why are you missing the current issue? Why are you always five years late? Yes I was ringing the bells about this then. Now it's time to finally compete with Facebook and Twitter. It might already be too late, but it might not be.

Why I moved off Heroku

I really appreciate the service that Heroku runs. It was a very easy way for me to get started in Node.js, and also very affordable! I kept marveling at what a great deal it was, gushed publicly about it, and paid them the highest honor, I developed my software around their architecture, so it would be really easy to deploy my stuff on Heroku.

My basic idea is that back-ends for software are very small things. They just move data out of the app, which runs in the browser on the user's desktop, to a storage place, and back out later. That's all the server has to do.

I designed it so that each app has its own server. That way if one of my apps got really popular, it wouldn't interfere with the others. This is ideal for developers, to have scaling be a totally fluid thing. That's why you want to chop the pieces as small as you can. Rather than try to host ten apps on a server, give each app their own server, no matter how small and insignificant. It's a design that can only work for a system like Heroku. It was really a breakthrough.

But, they changed their pricing so as to really discourage this architecture. It's possible they weren't even aware how their change would affect us. I didn't hide the design, I wrote lots of posts about it. I emailed with people there. I even met with their CEO on a trip to California to talk about how I saw their service and to learn how they were planning to evolve it. I kept emailing them asking if they were sure this is the deal and thanking them for their generosity.

But once they changed, I had to change. It no longer made sense to have lots of individual servers, one for each app. With the new economics. I'd have to bundle them up, the old way, where one server is running N apps. And if one gets successful, there's a bunch of manual work to set things up so it gets more resources without slowing the other apps down. Scaling is no longer a matter of sliding a slider on a browser interface. I wish it were.

Anyway it's up to them to decide how to price their service. And it was up to me to migrate when they changed their pricing. It was a pretty hellacious weekend here, lots of stress, but it's not bad. It's kind of like a basketball player has to get really intense to make it through the playoffs. This was a very high wire balancing act. But it was a good thing to do, now I have a much better understanding of what I've done. I've moved code I wrote when I was a total newcomer to Node.js. It wasn't a horrible experience!

And now I'm back on solid ground (knock wood, praise Murphy) I look forward to getting back to the stuff I really love, making new idea processing software that networks people in incredible new ways!

PS: A little more perspective in a post on my liveblog.

Hello Fargo users

This is a quick heads-up, there were major changes in the servers over the weekend. But if all went well, you should see no changes in the performance of Fargo.

Basically, I moved the back-end, Fargo Publisher, from Heroku to a server in Amazon's cloud. This is a lot like the move that Berkman made a few years back when they hoisted their building on Mass Ave and moved it a few blocks away, and re-planted it. It's as if all the scholars in the offices just went home for the weekend and came back to find their offices in a new location. Hopefully all the electric is properly hooked up, and the Internet, the bathrooms. Business as usual, they say. We hope.

Knock wood, praise Murphy, I am not a lawyer.

Dave

PS: There will be a new version of Fargo Publisher, shortly, if everything works. Haaha.

I would have hired Doug, but..

Philip Greenspun wrote a post on his Harvard blog about MIT grads over 50 having a hard time finding work. In his post he cites a piece I wrote about how I would have hired Doug Engelbart, when I was running my first startup in the 80s. His piece is getting a lot of traffic. That's good. I'm glad people are thinking about this.

My saying I would have hired Doug Engelbart in the 1980s means nothing about the job market in 2015. What I would have done in 1985 is irrelevant today. I'm not hiring. And I'm pretty sure my counterpart in 2015 doesn't feel the way I might have felt then.

I might have hired Engelbart because his work laid the foundation for the work we were doing at Living Videotext. He felt his work wasn't finished. We could have helped him achieve his vision, and he could have helped us make our software more useful. Perhaps we could have skipped years of evolution, avoiding the blind alleys he had to back out of in his earlier work.

Now the big wheel has turned and today I'm in the situation Engelbart was in in the 80s. Unlike Engelbart, I have re-tooled. I now work in JavaScript in the browser and on the server. I had to walk away from the codebase that I loved. I understood that the price of relevance is to give up fighting at some point and settle for a partial victory. I think I was right in the development environment I created. But right doesn't mean the world uses what you created. Maybe 20 or 30 years from now these ideas will have gained traction. I won't be programming then. I almost certainly won't even be alive.

I turned 60 over the weekend. It's a tough birthday, or it was for me. I didn't want to have it in public, so I told Facebook not to announce it. I think younger people don't understand. I finally think I understand how they don't understand. The ones that love me say I'm really young, and I appreciate that. I think they mean my thinking is flexible, and I'm excited about the future, like a young person might be. But the clock ticks in predictable ways. My body is that of a 60 year-old. And the world treats me as one as well. Most people can't see or feel the enthusiasm an older person has. Or they don't believe. Or they don't think.

Like Engelbart in the 80s, I feel my work is not done. I still pump out ideas executed in software at an amazing clip. I wonder why people don't wonder how I do it. The processes I use, investing in good tools and underpinnings, and paying attention to good features of other people's software, makes it easy and quick to try out new ideas. Some of them are really worth it. Look at the list of achievements on the smallpicture.com home page for an idea.

I want to share what I know. I want people to use my products. There's not that much road in front of me to get the work done. I'm pretty sure that there will be a lot left on my plate when I finally hang em up for the last time. I guess that's a sign of a rich and productive creative life.

PS: An earlier version of this post, on my liveblog, became the top item on Hacker News. Quite an interesting discussion ensued, with no slamming. Coooool.

If not now, when?

A picture named when.png

Professional users

I love testers. Great testers are essential. Or you could look at them as professional users. Or something else. But without them, software projects flounder.

One of the things I said to Doc yesterday is that if you can write a good bug report you'll do better as a user, because the problems you're hitting will move to the front of the queue. If I, as a developer, get a set of reproducible steps, that show how to recreate the problem, and steps work on my machine, I can usually fix the problem straight away. And I like to fix problems in my code.

The best user/tester I've ever worked with was Terry Teague. He had a day job at Apple as a tester, but contributed his time for free to various developer projects. We were lucky to have him as part of our team on Frontier. When we were preparing a new release, he'd put the product through its paces, and his bug reports were the best, hands down. Never seen anything like it. His steps-to-reproduce were clear, easy to follow, and almost always failed on my machine (failure in this case is success).

Unfortunately Terry died in 2005. And he's never been replaced.

We should be teaching young people how to be great users. How to contribute to the projects that make them more effective at doing what they do. The best form of contribution is to communicate clearly about ways the software isn't working.

There's a common, incorrect, belief that users don't matter, they can't do anything to help open source projects. Nothing could be further from the truth. Just having one user put a bit of serious concentrated time in working on my product made a huge difference for me as a developer. If Doc hadn't been willing to come to the phone and work with me, the problem would still be in the software. Who knows how many users suffered silently with this, or worse, just stopped using the product because they thought it was sabotaging their work (in a way it was). And how many more problems are waiting to be discovered, waiting until a user cares enough to get to the bottom of what input is producing the bad output.

Bottom-line: Software needs users to care about it.

"Reproducible"

A few weeks back, Doc posted a mysterious message to our support list, saying that blank headlines were showing up in his outline, and wanted to know if we knew what the problem was.

This is the kind of "bug report" that makes programming for users so frustrating. You hear a user is losing data, but have absolutely no idea how to reproduce the problem. It's something you've never seen the software do, can't imagine it actually doing. The description sounds like magic, but nothing in software happens by magic, all programmers will tell you. I believe it's happening but I have no idea why.

Anyway, the problem was still happening. We needed to get to the bottom of it. So I added a bit of instrumentation to the app. Every second it would look at all the headlines in the outline and count the number of empty ones, displaying the result on the screen. If it was greater than zero the message would show up in red. I wanted to be sure Doc would see it, the instant it happened.

I called him on Skype and said he should use the software as normal, and when he saw the number go above zero, to stop and think What Did I Just Do, and write me an email. This was my hope to try to get somewhere in the vicinity of reproducible.

He said it's reporting 9 empty headlines now. Okay, go through the outline, find them and fix them. Get that number down to 0 so we can start debugging.

So he did, and we talked a bit about this process while he was doing it.

Then when he was done, he was mousing around the outline and it happened. A headline disappeared.

I said loudly, now stop! Don't touch anything. Key question: What were you doing?

He said he was scrolling around the outline and scrolled back to the top and that was when he discovered the headline was empty.

Turns out it was very important just how he was scrolling around. He was using Pageup and Pagedown, two keys I never use. But for Doc they're central. And when he'd press Pageup or Pagedown, it would wipe out the bar cursor headline. Bing!

Would it do it on my machine? Drumroll please -- yes it would. So now the bug was trapped. I told Doc we had arrived at the Holy Moment in debugging -- reproducibility. I told him "reproducible" is the programmer's favorite word. If you can tell me the steps to reproduce the problem, then I can find it and fix it. Until it's reproducible all I can do is share your frustration.

There's a lot more to say about this. I asked Doc to write this up from his point of view. For me it was a breakthrough. Finally, a user who is working on the team with me, to help make the software work better.

Scoble asks about the Facebook API

Over on Facebook, my friend Robert Scoble asked how I feel about changes Facebook is making in developer access to the social graph. It was such an interesting question that I did a 10-minute podcast answering the question. Hope you find it interesting!

Great "Blue Sky" platforms

The hairball

Our current platform is a mess:

  1. CSS.

  2. HTML.

  3. JavaScript.

  4. A server.

Think of how much you have to learn to become "full stack" in this world.

At least four different syntaxes, and a CSS preprocessor.

HTML is XML. JavaScript is like C or Pascal. The server could be written in any number of different languages. And JSON. None of them are going away.

I've been working in this world for many years, and right now would be at a loss to write a canonical "hello world" app.

What a Tower of Babel. What an opportunity to topple it, esp given all the people these days who want to program.

It grows when it's simple

The big strides in tech happen when the platform gets reduced to simplicity. Examples include:

  1. Unix with C.

  2. Apple II with UCSD P-System.

  3. MS-DOS with Turbo Pascal.

  4. The Web with a plain text editor.

I call these blue sky platforms

In all these systems, lifting the hood is child's play.

Typing and modifying "Hello World" is easy. From there, there are no huge cliffs in the way of becoming a master.

1995: "A platform must have potential, or open space. I call this blue sky."

Digging out of the mess

We can get back to blue sky any time we want.

I would start from Node.js and build out.

The web browser, as currently configured would have to be replaced by something that's thoughtfully designed. Or maybe a platform built on top of CSS+HTML+JavaScript, hiding it behind a factored interface? Not sure. But we'll never have great growth until we factor out the huge hairball sitting between ideas and implementation.

I would have hired Doug Engelbart

I've heard it said, and thought myself, that of course I wouldn't have hired a 50-something developer when I was running my 20-something startup.

But then I just realized that if Doug Engelbart had wanted to work for Living Videotext or UserLand I would have hired him in an instant. Can you imagine. To have the guy who pioneered the technology we were commercializing around to mentor me and my developers? I would have jumped at the opportunity.

So the answer is, it depends. If it was a random employee type who hadn't done much with his or her career, I probably wouldn't have been very interested. But if it was someone who had created the foundation we were working on, that would have been different.

Guy Kawasaki: "Good people hire people better than themselves."

Update

I wrote a follow-up to this piece on May 6.

Imagine all the people

My Apple Watch podcast

I've made a dozen or more visits to the Apple Store website hoping to buy an Apple Watch and each time coming up empty and as confused as ever.

This 12-minute podcast tells the story.

BTW, here's a screen shot of the Apple website, referred to in the podcast.

Should Boston bid on the Olympics?

When I was chatting with Chris earlier today, the subject of the Olympics and Boston came up. Should Boston bid?

My two cents

Boston should not try to host the Olympics, in fact no one should. With climate change, a new venue for the Olympics every four years is an extravagance we can't afford. Sure it's a drop in the bucket but it's an important and symbolic drop in the bucket.

Build one great Olympic facility, designed to be usable for 100 years. Hold all future Olympics there.

It's like the United Nations. We don't build a new skyscraper every four years. We built one really good one, and use it every time we need the UN.

5-minute podcast

I was talking with Chris Lydon about the idea of a 5-minute podcast.

Then Doc Searls asked a question that I thought could easily be answered in 5.

I was right, but I rambled too much and it turned into a 6.5-minute podcast.

Next time we'll do better!

The open tech of Podcatch.com

On Friday, as you may know, I made Podcatch.com public.

It's a quick way to find a great podcast to listen to, now. Without subscribing.

The list of feeds is curated, it originated from the feeds my Facebook friends liked the most. In that I think it's a prototype for how social networks can be used to create new flows that aren't complicated or hard to use or appreciate. I think, btw, this is the holy grail Twitter has been looking for.

The JavaScript environment

What I haven't talked about yet is all the great open technology it builds on. Stuff that's available to anyone to use to create new apps. One of the amazing things about developing in JavaScript in 2015, and hasn't been well-appreciated yet, is how deep and generous the developer community is, to itself. I've never seen anything like this.

Technologies we use

So here's a partial list of technologies I'm using to make this work, all of which are open source and available to all, free of charge and on equal terms.

  1. Font-Awesome for the icons.

  2. Bootstrap Toolkit for the CSS framework.

  3. jQuery to make access to the DOM uniform across browsers.

  4. snap.js manages the sidebar in the app (new feature today).

  5. River4, manages subscriptions, river generation and browsing.

  6. Feedparser does all the feed parsing for River4.

  7. OPMLparser reads the subscription lists for River4.

  8. RSS is what podcasting is built on, of course.

  9. Node.js runs the custom back-end Podcatch software and River4.

  10. NPM supports the building of the backend bits.

  11. V8 which is the JavaScript interpreter in Node.js.

  12. HTML5 has an

  13. Google Fonts for Oswald and Ubuntu.

Thanks!

Thanks to all the generous developers (with a caveat that I am thanking myself for River4 and RSS, I know it's weird).

I'm sure this list will grow as I remember more bits of generosity that I'm building on.

This tech makes people rich

BTW, one of the reasons I listed the open tech that podcatch.com builds on is to increase the visibility of these essential components.

For entrepreneurs and VCs who have made billions from tech, you should know that this would not be possible without the generous work of people who mostly do it for love, with no expected remuneration.

If you think you support open tech and are not actively supporting this work, you're not. Sometimes you have to tell truth to power. This is one of the truths that has not been well-told.

The new WTC elevator

One of the things I love about NYC history is the layering and the continuity. It's how I think software should evolve too. We rip up our software cities too easily, because we don't like the arrangement of the streets, forgetting that there are real people living and working in our cities.

So I totally got off on the elevator movie that takes you to the 102nd floor observation deck in the new WTC tower. It shows you how the city evolved from nothing to a small Dutch settlement at the tip of Manhattan (south of the WTC site) to the huge metropolis it is today. You even get a look, briefly, at the ill-fated tower that came down on 9/11.

But there are mistakes, as has been observed, and one howler that as far as I know has not been reported yet. Here's the problem. They show the Brooklyn Bridge, clearly, in 1825. But it wasn't finished until 1883.

T-Mobile travails

I was taking an early morning walk in Manhattan this morning when the fourth wall popped with T-Mobile. I was dropped out of The Matrix and smack in the mire of post-millennial mobile access.

My recently-upgraded T-Mobile account was missing a vital feature. I found out about it just as I was getting ready to use a service that requires a net connection.

The 20-minute story in a podcast.

The future of journalism

There's a future-of-journalism conference in Austin. I'd like to insert a recipe, if I can, for the future of journalism.

  1. Start by solving problems. In all likelihood the geography you serve (if you are geography-based) has awful Internet connectivity. Before doing anything else, you must take ownership of that problem. If your readers have lousy Internet they will not be full participants in the world-wide news system. NYT, NYP, NYDN take note please.

  2. Work on your collective rolodex. That is the definition of who you are. The better it is the better you are. I'd be surprised if many current news orgs see it that way. But they will. (By the way you can start on this step before the previous step is complete. It might take years, even decades.)

  3. Make sure you have in your rolodex a field called "Feed" and in that field include the address of your source's RSS (or Atom I don't care) feed. You're going to need it in step 4.

  4. Make a river out of those feeds. Start watching that river. Tell your sources about the river, give them the address. About five minutes after that you will be jumping up and down with excitement. Five minutes after that it will be on your home page.

  5. Congratulations, you now have a future.

Introducing Podcatch.com

I was bored with my podcasts. I subscribed to a dozen different feeds, but was only listening to two shows. Sometimes I'd leave the house with nothing interesting on my phone. I muddled along, thinking this was the best I could do. Then came Serial, and all of sudden podcasting was exciting again. I looked forward to every week's installment the same way I look forward to a weekly Game of Thrones or Mad Men.

A fog of podcasts

What followed was an explosion of new podcasts, or so it seemed, but which were the good ones? I did what everyone does, I asked my friends. I saw my friends asking. I asked again. Sometimes I found something interesting to listen to, but usually not something I wanted to subscribe to. That got me thinking.

Subscribing may be the wrong way to look at it. When I want a podcast I don't want to subscribe. I want to listen. All the time between the want and the fulfillment seems like work. Why is this so hard.

I tried an experiment

Standing on the street in Manhattan, with my iPhone 6 and a good net connection, how long would it take me to find something to listen to.

In other words, how long after having the idea "I want a podcast" did it take to fulfill it. Standing out there in the cold. Feeling like an idiot, fussing with my phone.

How long? A lot longer than it should.

An idea from Vox

Then I read an article in Vox that listed 26 podcasts I should be listening to. There's the answer. Almost. If they had a page that followed all these podcasts, I could go there, click a play button and be listening in an instant. Someone with good judgement chose these shows, and I bet one or two of them are good in any week. But that place didn't exist.

Another experiment

I asked my friends on Facebook to recommend their favorite podcasts. I figured if we were friends, or friends-of-friends, some of our interests would overlap. But I did more than ask, I engaged. And I didn't ask for feeds, I was willing to do the research to go from the title of the podcast to the RSS feed.

I set up a river, customized it so there was a player for each item, and linked it up with Facebook comments, so the resulting conversations would feed back into my relationships.

The product

As Apple says about their products, it has magic. It's simple, it's probably not what you expect, but it really works. When I go there, I find new ideas, feelings, perspectives, entertainment.

That's Podcatch.com.

And now it's public. You can use it too!

A picture of a slice of cheese cake.

It's their world we just live in it

Something funny happens when I put my iPhone 6 and my Nexus 6 together on my desk (charging them up).

The iPhone tries to pay the Nexus using ApplePay.

I just realized how funny this is. Why does the iPhone (Apple) think it owes the Nexus (Google) money?

Next time it happens I'm going to make note of how much money the iPhone thinks it owes the Nexus.

Software and free hardware

I just saw that JJ Abrams has an Apple Watch.

You know there was a time when I would have had that.

When Apple gave early access to hardware to developers who created software for their platform. I was, at one time, one of those people.

I used to have a motto back then: "Software is made of free hardware."

What was cool is that it worked the other way too. Hardware is made out of free software. But that was hard to say because of piracy, could be too easily misunderstood. Still, it's true.

And it makes me wonder if there isn't still a position for a company to do what Apple used to do, cultivate relationships with software-makers.

Pretty sure JJ doesn't write too much software.

XML