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

#기수_블친소 #기수_트친소 #블친소 전국멜로디협회, 전국앨리슨협회 깃발의 그 사람입니다. 가끔은 MLP 트왈라 인형도 들고 다닙니다. 가능할 때마다 여의도, 광화문, 한남동 등 어디든 윤석열 탄핵 집회 (그리고 그 이외에도 참여하고픈 수많은 집회들) 참석합니다. 선팔 및 멘션 적극 환영합니다.

0
0
0
0
0
0
0
0

■ notestockの豆知識(TIPS)

Mastodonの検索欄で、以下の文字列を検索してみてください。

notestock.osa-p.net

サーバが認識していれば、 :notestock_icon: notestockが提供している様々なサービスのアカウントが一覧されます。

(Misskey系はこういうのみつけにくいかも)

添付のスクリーンショットや下記のURLからたどってご確認ください。
notestock.osa-p.net/about.html

『fediverse情報』は、お役立ち情報をまとめて伝えるアカウントです。

『時刻お知らせ』は、一時間に一回だけ時刻を伝える時間ばさみアカウントです。

『voteguide』は、実施中の投票の情報をフォローアップするアカウントです。

サイトには、証明書期限切れしそうなサーバのリストとか、サーバー紹介投稿をまとめたもの、カスタム絵文字の検索、遅延状況など、面白いサービスがいっぱい並んでいますよ。

notestock.osa-p.netの検索結果のスクリーンショット

stocker, fediverse情報, 時刻お知らせ, voteguide, デバッグ, バルス
0
0
0
0
0
0
0
0
0
0
0
0

어젯밤 데비안 패드 벽돌 될 것 감수하고 데비안 12로 업그레이드했는데 생각보다 문제 없이 잘 돼서 신남! ^ㅁ^ 전부터 느끼지만 그놈 데스크톱 환경은 예상 외로 터치 친화적인데... 터치로 쓰는 사용자가 생각보다 많은 걸까?

이 이미지는 어두운 표면 위에 세워진 태블릿 기기를 보여주고 있으며, 은색의 데스크탑 앞에 기대어져 놓여 있습니다. 이 기기는 하단에 Windows 로고가 있고 여러 화면을 표시하고 있습니다.
화면 상단에는 "hackers.pub" URL과 탐색 요소가 표시되어 있습니다. 메인 화면에는 "Hackers' Pub"이라는 웹페이지가 표시되어 있으며, 한국어 텍스트와 영어 요소가 포함되어 있습니다. 대화 영역에는 "I can't type Korean. T.T"라는 메시지가 보입니다. 
화면 하단에는 "Winbook TW802", "2.0 GiB" 메모리, "Intel Atom Z3735F", "Mesa Intel HD Graphics", "30.6 GB" 디스크 용량과 같은 기기에 대한 시스템 정보가 표시되어 있습니다. 운영 체제는 "Debian GNU/Linux 12 (bookworm)"인 것으로 보입니다.
기기의 상태 표시줄에는 날짜와 시간(3월 11일 14:25:15), 배터리 수준(88%) 및 연결 아이콘이 표시되어 있습니다. 또한 기기 상단에 작은 너구리 라면 스티커가 보입니다.
0

Evan Prodromou shared the below article:

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

어젯밤 데비안 패드 벽돌 될 것 감수하고 데비안 12로 업그레이드했는데 생각보다 문제 없이 잘 돼서 신남! ^ㅁ^ 전부터 느끼지만 그놈 데스크톱 환경은 예상 외로 터치 친화적인데... 터치로 쓰는 사용자가 생각보다 많은 걸까?

이 이미지는 어두운 표면 위에 세워진 태블릿 기기를 보여주고 있으며, 은색의 데스크탑 앞에 기대어져 놓여 있습니다. 이 기기는 하단에 Windows 로고가 있고 여러 화면을 표시하고 있습니다.
화면 상단에는 "hackers.pub" URL과 탐색 요소가 표시되어 있습니다. 메인 화면에는 "Hackers' Pub"이라는 웹페이지가 표시되어 있으며, 한국어 텍스트와 영어 요소가 포함되어 있습니다. 대화 영역에는 "I can't type Korean. T.T"라는 메시지가 보입니다. 
화면 하단에는 "Winbook TW802", "2.0 GiB" 메모리, "Intel Atom Z3735F", "Mesa Intel HD Graphics", "30.6 GB" 디스크 용량과 같은 기기에 대한 시스템 정보가 표시되어 있습니다. 운영 체제는 "Debian GNU/Linux 12 (bookworm)"인 것으로 보입니다.
기기의 상태 표시줄에는 날짜와 시간(3월 11일 14:25:15), 배터리 수준(88%) 및 연결 아이콘이 표시되어 있습니다. 또한 기기 상단에 작은 너구리 라면 스티커가 보입니다.
0
0
0

14:45あたりに予約投稿投げておくか。

Fedibirdには予約投稿の完了通知があるから投稿された瞬間に通知がくるけど、普通のサーバだとわからないよね。

サブアカウントにメンション入れておいて、そっちで見るぐらいしか方法ないかも?

0
0
0

‘딥시크 돌풍 진원’ 저장대 교수의 과로사…혁신은 이렇게 스러진다 (경향)
- 48세 재료공학자 류융펑 뇌출혈 사망
- 쓰러지기 전까지 10개월간 319일 일해
- 중국 각지서 연구자들 돌연사 잇달아
- 국내선 ‘주 52시간 노동’만 주목하지만
- 과로의 일상화, 지속 가능한지는 의문
khan.co.kr/article/20250311120

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

One thing that doesn't get much attention in the EU vs. US jostling over control of the social web, is the huge number of people in Asian countries running fediverse servers.

A huge chunk of the fediverse is writing in Chinese characters, or Japanese or Korean, or in the trade languages of the Indian subcontinent. Yet I've seen no formal participation from those communities in fediverse Dev chatter.

How can we internationalise fediverse Dev? Is it language barriers? Cultural ones?

0
0

Lynx - 웹 기술 기반 네이티브 앱 개발 도구
------------------------------
- 틱톡(ByteDance)이 만든 더 빠르고 부드러운
React Native 대체제
- Lynx는
웹 기술을 사용해 네이티브 UI를 생성할 수 있도록 돕는 기술 패밀리
- 하나의 코드베이스에서 모바일과 웹등 다양한 플랫폼에 대응 가능
- TikTok과 같은 대규모 앱에서 성능 중심의 UI 프로그래밍 및 Rust 기반 툴링을…
------------------------------
https://news.hada.io/topic?id=19688&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
0
0
0