What is Hackers' Pub?

Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.

0
0
0
0
0
0
0

それとも、感情にまかせて俺を殺しますか?敵だった女のために、この

0

Hackers' Pub 쓰고 계신 분들 중에서, 자신의 Hackers' Pub 계정을 연합우주(fediverse)뿐만 아니라 Bluesky에도 노출하고 그쪽 사람들과 교류하고 싶으신 분이 있다면, 상단 검색창에 @bsky.brid.gy@bsky.brid.gy을 검색하셔서 나오는 프로필을 팔로해 보세요. 그리고 1분 정도 뒤에 Bluesky에서 본인ID.hackers.pub.ap.brid.gy로 검색하면 본인의 Hackers' Pub 계정이 Bluesky에서도 보이는 걸 확인하실 수 있을 겁니다.

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

昨日と今朝は主にバグ修正だけだった。

  • 非公開の投稿は共有を出来なくした
  • Markdown のレンダリングで GitHub スタイルのコールアウトのバグを修正
  • AUTHORIZED_FETCHが適用されたインスタンスからノートオブジェクトのリクエストを受けた時、無条件に401が出るバグ修正(Fedifyまでまとめて修正…)
  • 脚注リンクが動かないバグ修正
  • 他の人のDMがタイムラインに表示されるバグを修正
  • ファビコン追加
0

昨日と今朝は主にバグ修正だけだった。

  • 非公開の投稿は共有を出来なくした
  • Markdown のレンダリングで GitHub スタイルのコールアウトのバグを修正
  • AUTHORIZED_FETCHが適用されたインスタンスからノートオブジェクトのリクエストを受けた時、無条件に401が出るバグ修正(Fedifyまでまとめて修正…)
  • 脚注リンクが動かないバグ修正
  • 他の人のDMがタイムラインに表示されるバグを修正
  • ファビコン追加
0

어제랑 오늘 오전은 주로 버그 수정만 했다.

  • 비공개 게시물은 공유 못 하게 막음
  • Markdown 렌더링에서 GitHub 스타일 콜아웃 버그 고침
  • AUTHORIZED_FETCH 적용된 인스턴스로부터 노트 객체 요청 받았을 때 무조건 401 떨어지던 버그 수정 (Fedify까지 덩달아 수정…)
  • 각주 링크 작동 안 하던 버그 고침
  • 다른 사람 DM이 타임라인에 뜨던 버그 고침
  • 파비콘 추가
0

어제랑 오늘 오전은 주로 버그 수정만 했다.

  • 비공개 게시물은 공유 못 하게 막음
  • Markdown 렌더링에서 GitHub 스타일 콜아웃 버그 고침
  • AUTHORIZED_FETCH 적용된 인스턴스로부터 노트 객체 요청 받았을 때 무조건 401 떨어지던 버그 수정 (Fedify까지 덩달아 수정…)
  • 각주 링크 작동 안 하던 버그 고침
  • 다른 사람 DM이 타임라인에 뜨던 버그 고침
  • 파비콘 추가
0
0
0

SNSよりも行政の方が信頼性高いから、これをブックマークしておくと良いよ。
各都道府県の防災ポータル一覧。住んでる都道府県のページを見れば、行政からの情報がまとめて得られるので。

こういう話を普段からSNSでしといて、情報を整理するのは有益でいいね。

国土交通省 防災ポータル
mlit.go.jp/river/bousai/bousai

0
0
0
0
0
0

拡散希望:開発中のプロジェクトHackers' Pubの日本語ベータテスターを募集します!

これはフェディバース版のQiita/Zennを目指す、ActivityPub基盤の開発者向けSNS兼ブログプラットフォームです。AGPL-3.0ライセンスでソースコードを公開しており、GitHubでプロジェクトも公開進行中です。

現在韓国語話者中心に招待制ベータテスト中ですが、日本の開発者コミュニティにも広げたいと思っています。ソフトウェア開発に興味がある方、フェディバースが好きな方、新しいプラットフォームを試してみたい方、ぜひご参加ください!興味のある方はリプライかDMでメールアドレスをお送りください。

0
11
0
0
0
0

私、自分が知らない人って認識してる人に対する受容性まったく持ち合わせてないんだなって思った。YouTuberさんが話してるのとかゾワゾワして聴いてられないし高校野球みたいな見知らぬ学生がやってるスポーツも見れないし… 突然何の話だろうねこれ……(?)

0
0
0

Ten years ago today I coined the shorthand “js;dr” for “JavaScript required; Didn’t Read” * https://tantek.com/2015/069/t1/js-dr-javascript-required-dead in reference to (primarily content) pages that were empty (or nearly so) without scripts. Since then js;dr found its way into a book: Page 88 of “Inclusive Design Patterns” by @heydonworks.com (@heydon@front-end.social) Cropped photo of part of page 88 of Inclusive Design Patterns at an angle and stickers! A hand holding about a dozen stickers with the “js;dr” in black on white text die-cut around the edges of the lettering At the time I made the claim that: “in 10 years nothing you built today that depends on JS for the content will be available, visible, or archived anywhere on the web.” I’ve seen and documented many such sites, built with a hard dependency on scripting, that end up dead and unarchived. Many of these have been documented on the IndieWeb’s js;dr page: * https://indieweb.org/js;dr I have to ask though: does anyone remember building a site 10 years ago (Internet Archive citation) with a Javascript library/framework dependency to display content, that still works today? E.g. using one of the popular libraries/frameworks used to build such sites back then like AngularJS (discontinued 2022), Backbone.js, Ember.js, or even React which was still quite new at the time. The one almost exception I found was Facebook, e.g. this Smashing Magazine post on Facebook barely renders some content and all commentary is missing, in the earliest (2019) version saved on the Internet Archive: * https://web.archive.org/web/20191123225253/https://www.facebook.com/smashmag/posts/10153198367332490 You can extract the direct Facebook link if you want to try viewing it in the present. Regarding those libraries/frameworks themselves, I wrote: “All your fancy front-end-JS-required frameworks are dead to history, a mere evolutionary blip in web app development practices. Perhaps they provided interesting ephemeral prototypes, nothing more.” Of all those listed above, only React has grown since, likely at the expense of the others. However instead of fewer such libraries and frameworks today, it seems we have many more (though it feels like their average hypespan is getting shorter with each iteration). Since I wrote “js;dr”, the web has only become more fragile, with ever more dependencies on scripting just to display text content. The irony here is that Javascript, like XML, has draconian parsing rules. One syntax error and the whole script is thrown out. This means it’s far too easy for any such JS-dependent site to break, in one or more browsers, whenever browsers change, or Javascript changes, or both. You wouldn’t build a site today (or 20 years ago) that depends on fragile draconian XML parsing, so why build a site that depends on fragile draconian Javascript parsing? I’ll repeat my claim from ten years ago, slightly amended, and shortened: In 5 years nothing you (personally, not a publicly traded company) build today that depends on Javascript in the browser to display content will be available, visible, or archived anywhere on the web. There’s a lot more to unpack about what we’ve collectively lost in the past ten years of fragile scripting-dependent site-deaths, and why web developers are choosing to build more fragile websites than they did 10 or certainly 20 years ago. For now I’ll leave you with a few positive encouragements: Practice Progressive Enhancement. Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques. All content should be readable without scripting. Links, buttons, text fields, and any other interactive HTML elements should all work without scripting. Scripts are great for providing an enhanced user experience, or additional functionality such as offline support. Then make sure to test your pages and sites without scripts, to make sure they still work. If it's worth building on the web, it's worth building it robustly, and building it to last.

Tantek Çelik @tantek.com@fed.brid.gy

Ten years ago today I coined the shorthand “js;dr” for “JavaScript required; Didn’t Read”

* https://tantek.com/2015/069/t1/js-dr-javascript-required-dead

in reference to (primarily content) pages that were empty (or nearly so) without scripts.

Since then js;dr found its way into a book:

Page 88 of “Inclusive Design Patterns” by @heydonworks.com (@heydon@front-end.social)

Cropped photo of part of page 88 of Inclusive Design Patterns at an angle
and stickers!

A hand holding about a dozen stickers with the “js;dr” in black on white text die-cut around the edges of the lettering

At the time I made the claim that:

“in 10 years nothing you built today that depends on JS for the content will be available, visible, or archived anywhere on the web.”

I’ve seen and documented many such sites, built with a hard dependency on scripting, that end up dead and unarchived. Many of these have been documented on the IndieWeb’s js;dr page:

* https://indieweb.org/js;dr

I have to ask though: does anyone remember building a site 10 years ago (Internet Archive citation) with a Javascript library/framework dependency to display content, that still works today?

E.g. using one of the popular libraries/frameworks used to build such sites back then like AngularJS (discontinued 2022), Backbone.js, Ember.js, or even React which was still quite new at the time.

The one almost exception I found was Facebook, e.g. this Smashing Magazine post on Facebook barely renders some content and all commentary is missing, in the earliest (2019) version saved on the Internet Archive:
* https://web.archive.org/web/20191123225253/https://www.facebook.com/smashmag/posts/10153198367332490

You can extract the direct Facebook link if you want to try viewing it in the present.


Regarding those libraries/frameworks themselves, I wrote:

“All your fancy front-end-JS-required frameworks are dead to history, a mere evolutionary blip in web app development practices. Perhaps they provided interesting ephemeral prototypes, nothing more.”

Of all those listed above, only React has grown since, likely at the expense of the others.

However instead of fewer such libraries and frameworks today, it seems we have many more (though it feels like their average hypespan is getting shorter with each iteration).

Since I wrote “js;dr”, the web has only become more fragile, with ever more dependencies on scripting just to display text content. The irony here is that Javascript, like XML, has draconian parsing rules. One syntax error and the whole script is thrown out.

This means it’s far too easy for any such JS-dependent site to break, in one or more browsers, whenever browsers change, or Javascript changes, or both.

You wouldn’t build a site today (or 20 years ago) that depends on fragile draconian XML parsing, so why build a site that depends on fragile draconian Javascript parsing?


I’ll repeat my claim from ten years ago, slightly amended, and shortened:


In 5 years nothing you (personally, not a publicly traded company) build today that depends on Javascript in the browser to display content will be available, visible, or archived anywhere on the web.


There’s a lot more to unpack about what we’ve collectively lost in the past ten years of fragile scripting-dependent site-deaths, and why web developers are choosing to build more fragile websites than they did 10 or certainly 20 years ago.


For now I’ll leave you with a few positive encouragements:


Practice Progressive Enhancement.

Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques.

All content should be readable without scripting.

Links, buttons, text fields, and any other interactive HTML elements should all work without scripting.

Scripts are great for providing an enhanced user experience, or additional functionality such as offline support.

Then make sure to test your pages and sites without scripts, to make sure they still work.


If it's worth building on the web, it's worth building it robustly, and building it to last.

Read more →
0
0
0
0
0
0