I wanted to mark a milestone. I finally have a web server running out of a Dropbox folder. I tried doing this with Apache a few years ago, but there was something about how Apache worked that drove Dropbox crazy. Or vice versa.

Now I have my own web server, written in JavaScript, built out of Node.js core packages. It's really fast and reliable, and I pretty much know exactly what it's doing. There was never a problem with Dropbox. We just read the files from the server. We update our own stats files, but that doesn't seem to be too much for Dropbox to handle. (It is using up a lot of CPU cycles on the server, according to the Top command, so I'm thinking about turning Dropbox off when I'm not actively developing.)

Why it's so cool -- all my tools work with the filesystem. It's even more widely supported than Git. And there's no difference between the original content and the stuff that's being served. If I want to edit one of the files in my website, I just open it in an editor, make the changes and save. It's like having the server on my machine, without actually having the server on my machine.

The server is called PagePark. Of all my latest tools, it's my favorite. I love tweaking it, adding little shortcuts. Things that make it work really well for the kind of content I serve.

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.

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.

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.

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.

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.

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.

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.

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.

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.