HN user

gpnt

281 karma
Posts4
Comments39
View on HN

This is the routine I perfected for myself as a nomad after a lot of trial and error:

- In the morning, I work at the Airbnb/hotel. I start the day without worries about packing/unpacking or preparations: a solid three to four hours of work. (Requirements: get a room with a workstation and a good chair. Tables are usually easy to find, but if the chair isn’t good enough, buy one.)

- Natural stop to have lunch, usually with a longer walk.

- Start work again around 2 PM at some coffee shop and order a coffee. Another three hours of solid work.

- Natural stop to use the bathroom (always a problem as a solo nomad, but not anymore), stretch my legs, and head to a different coffee shop.

- Final batch of work. Order something light to eat. No more caffeine. Another three hours of solid work.

In the end, I can get between nine and ten hours of solid work per day. I spend around three hours in one place, so I didn’t notice any uncomfortable looks.

I also don’t rely on power outlets or local Wi-Fi never. The laptop needs to last the entire time, but it’s easy because it’s only in the afternoon (around six hours, not the whole day). For Wi-Fi, I always get a good mobile package with unlimited data if possible. This makes it easy to sit anywhere, really.

My setup is usually my laptop, an iPad as a second screen, earbuds, and a mobile phone. It works like a charm.

I am having the same problem recently. I want to get a degree in a non-tech-related area, Biological Science, but although there are online options, they are expensive, and this degree in particular has a lot of lab work. I also considered going back to my country, where university is free (but with a tough national exam to enter), but the idea of doing the degree with people 30 years younger doesn't sound exciting to me. So I’m kind of thinking about a risky path: building a curriculum with a reasoning AI model, matching it with textbooks (I don't like classes, I prefer learning from books), and studying by myself while documenting everything, so I could apply for a master’s or PhD later on (the risky part). About the labs, I will talk to some colleges and see if I can attend locally with non-degree credits. Not sure if this will work, but every other option seems worse.

I wonder why there isn't a program for self-taught students that provides validation for their efforts, like exams and access to local labs, but no classes. I believe a lot of older adults would like to go back to school but don't want to be in an environment that hasn’t even been remotely designed with them in mind.

Well, you are using javascript anyway so here it is a 163 bytes solution without the back button problem and iframe hack:

<script>onclick=async e=>{x=e.target.dataset.x;if(x){e.preventDefault();document.querySelector(x).innerHTML=await fetch(e.target.href).then(r=>r.text())}}</script>

<a href="/somepage" data-x="#lib">Hi</a>

<div id="lib"></div>

doesn't works with form though.

Show HN: Hyperdata 6 years ago

A few days ago, I released WDR (Web Data Render), a simple idea to separate website data and presentation. It received a lot of attention[1] and invaluable feedback! But a lot of the comments focused on the rendering part, and the data part is much more interesting, in my opinion. The website being a valid JSON with pure data is very powerful. Today, I'd like to introduce Hyperdata. A simple way to get information from any JSON website. I hope you like it. Your feedback is very welcome.

[1] https://news.ycombinator.com/item?id=25352385

The website uses the basic render, that is just a start to make it easy to create a page quickly. But ideally, you create a custom render, that will not depend on the order.

You are correct. Sometimes, some markup is inevitable. You can try to break down the information to render separately, but it is not always possible. So I think a little bit of markdown would be an acceptable compromise.

I think a hard problem ahead would be how to convince other people to also adopt this framework, and how to make sure that people are using the same JSON keys to mean the same thing.

At first, I was thinking to use some kind of general schema, but those things never work. So I decided something much simpler: the render determines the schema. This is an important aspect that I am working on. If you choose some specific render, your JSON will have a specific shape. For example, if the render is for a landing page, the JSON could be something like "about", "products", "team", etc. (never <section>, <h1>, etc...). But it is too soon to tell I'm still thinking about it.

(but an interesting corollary is that the render could be also a program with the "config" part. It would be an alternative to website builders. Every render would be a different WB tailored for the website)

I'm curious how you plan to prevent your JSON format from being (ab)used for presentation purposes, where people add extra content to make the page display a certain way. And if you have a plan, is this plan feasible using HTML as well?

I don't have a plan for that yet, and it will be difficult because we are accustomed to mixing data+markup. But I think the mindset is to stop thinking the website for just the browser. The website could be information first, presentation later.

I don't see this error on FF. Are you seeing this on the console?

I put the meta tag to render some special characters without relying on the server, but HTTP header would be a better option (Content-Type: text/html; charset=utf-8).

And you nailed the process.

I think it is early to make more conclusions, but I had to adjust my way of thinking to work with WDR. We are so accustomed to thinking data+markup that it is hard to imagine any other way. So, I started to create the JSON data without thinking about the design at all. "What information I would like to see on this page", and I created the JSON thinking only on that. It turns out, creating the render afterward was much easier and faster (and pleasant). It is, at least for me, a new way to think about the page.

The idea is to separate the data in JSON completely to be consumed outside the browser if needed, but still render correctly in the browser. The traditional javascript framework only solves the latter.

I tried to solve the quirks mode, but it is kind of hilarious that the browser needs the odd <!doctype html> to flip to standard mode. There are ways to inform the doctype on the headers or XHTML, but this would complicate a simple solution. But I was quite surprised how consistent is the look on different browsers, at least in the modern ones.

Yes, this is a good catch. The reason for this is the basic render that I created is generic, and it is not what you should do to render your JSON. The render should fit perfectly with the JSON. The basic render is just for a quick start.

For example, the basic render "# Title" creates an h1 header, but if you created the render, you know the internal schema of the JSON, so you can use the correct HTML element for that without recurring to this hack.

But the principle is important: try not to use markup on the JSON, because this would make it difficult for others to consume your website with JSON.

I tested only on small websites, but the performance that I am experienced surprised me a bit. The render is very small and fast and as you said, like the JSON page (that it is also very small because there aren't any HTML tags), very cacheable. More testing is needed.

I created this tool with a very odd necessity: I hate animations and overlay ;). I would like to have access to the website data directly and build my own interface, but for this, I would have to have access to the information only. I know that the website could expose an API, but WDR feels much more natural and easy (try to do a `fetch` on the page and get the JSON instantly).

Now that I have built and have played around a bit, I don't see how can I build a website in any other way.

For me, the website's information is important, not the design. WDR exposes that.