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

Most software engineers focus on efficiency rather than effectiveness.

What matters more: solving a $1M problem with 90% efficiency, or solving a $1K problem with 99.999% efficiency?

Efficiency matters, but there are infinite wants and scarce people to solve them.

Differentiate yourself by knowing when to stop optimizing and help your org deploy time more effectively.

0

각종 여론조사는 모수를 보정하게 되는데 그 보정하는 값이 이전 여론조사에 의존한다면 어떻게 되는거지?
인구 통계야 정확하게 있다지만 정치쪽은 평소 지지하는 정당을 가지고 보정을 할텐데 그 평소 지지하는 정당은 국가에서 각 잡고 통계를 낸 게 아니라 이전에 똑같이 여론조사 해서 나온 결과고 그것도 성별/나이/지역으로 보정한 결과일거잖아

0

Beachpatrol - 브라우저의 일상 업무를 자동화하는 CLI 허브
------------------------------
- 일반 웹 브라우저를 *CLI 기반 자동화 브라우저* 로 대체할 수 있게 해주는 오픈소스
- 이메일·은행·SNS 자동 체크, 파일 자동 다운로드, 텍스트 추출 및 저장
- 폼 자동 입력, 사이트 맞춤 메시지 수집, Bash·Python 스크립트 연동
- *일상적인 웹 브라우징 환경 전체를 자동화* 할 수 있음
- Play…
------------------------------
https://news.hada.io/topic?id=21349&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
0
0
0

I found out it is harder to publish an app to the Play Store than is is to publish an app to the App Store. To publish to the Play Store you need 12 testers. Does Google know how hard it is to make friends?

If you are on want to try out a super simple app with a gorgeous map of the Netherlands (map5topo.nl), DM me your e-mail and I will add you as a tester.

Screenshot of map app, showing Naarden.
0

@hollo 같은 얘기입니다ㅋㅋ근데 하스켈에서 '요청을 보내되 응답은 다른 쓰레드에서 받기'란 이펙트를 구분할수가 없지 않나요? 새 쓰레드를 띄울수있는 이펙트랑은 좀 다르다고 생각합니다. 새로 쓰레드를 띄우면 거기서 무제한으로 요청/응답을 할수있는데 그걸 바라진 않아서요.

1
0
0
0
0

TrinityNYC:
"現地の住民が皆、LAで「暴動」など起こってないと言ってるのに、ああしてわざと兵力を投入して暴力を煽り、戦争状態を作り上げて挑発し、平和的なプロテストが文字通りの暴動に発展するのを舌なめずりして待ってるんだ。暴動が起これば、戒厳令を発して、楯突く者を一網打尽に逮捕投獄して、他の都市への見せしめにできるからな。" — Bluesky
bsky.app/profile/frankie0320.b

0
0
0
0
0

GeekNews Weekly #309 Mary Meeker의 "AI" 트렌드 보고서
------------------------------
“인터넷의 여왕”이라는 별명을 가진 Mary Meeker는 1995년부터 거의 매년 Internet Trends라는 보고서를 통해 인터넷 산업의 다양한 발전상을 조망해 왔습니다. 2018년 클라이너 퍼킨스를 떠나 자신의 VC인 Bond Capital을 창업한 이후로는, 더 바빠진 탓인지 2019년을 마지막으로 인터넷 트렌드 보고서가 나오지 않아 아…
------------------------------
https://news.hada.io/weekly/202523?utm_source=googlechat&utm_medium=bot&utm_campaign=1834

0
0
0
0
1
0

洪 民憙 (Hong Minhee) :nonbinary: shared the below article:

Backfilling Conversations: Two Major Approaches

julian @julian@community.nodebb.org

<p>In February 2025, I presented a topic at FOSDEM in Brussels entitled <a href="https://spectra.video/w/xwCSYfZh1mJY64zJ9GngbE" rel="nofollow ugc">The Fediverse is Quiet — Let's Fix That!</a> In it, I outlined several "hard problems" endemic to the fediverse, focusing on one particular complaint that is often voiced by newcomers and oldtimers alike; that the fediverse is quiet because you don't ever see the full conversation due to some design considerations made at the protocol level.</p> <p>Since then there have been a number of approaches toward solving this problem, and it is worth spending the time to review the two main approaches and their pros and cons.</p> <p><em>N.B. I have a conflict of interest in this subject as I am a proponent of one of the approaches (FEP 7888/f228) outlined below. <strong>This article should be considered an opinion piece.</strong></em></p> <hr /> <h2>Crawling of the reply tree</h2> <p>First discussed 15 April 2024 and merged into Mastodon core on 12 Mar 2025, <a href="https://neuromatch.social/@jonny">@<bdi>jonny@neuromatch.social</bdi></a> pioneered this approach to "fetch all replies" by crawling the entirety of the reply tree. When presented with an object, the Mastodon service would make a call to the <code>context</code> endpoint, and if supported(?) would start to crawl the reply tree via the <code>replies</code> collection, generating a list of statuses to ingest.</p> <p>This approach is advantageous for a number of reasons, most notably that <code>inReplyTo</code> and <code>replies</code> are <strong>properties that are ubiquitous</strong> among nearly all implementations and their usage tends not to differ markedly from one another.</p> <p><em>N.B. I am not certain whether the service would crawl <em>up</em> the <code>inReplyTo</code> chain first, before expanding downwards, or whether <code>context</code> is set in intermediate and leaf nodes that point to the root-level object.</em></p> <p>One disadvantage is this approach's <strong>susceptibility to network fragility</strong>. If a single node in the reply tree is temporarily or permanently inaccessible, then every branch of the reply tree emanating from that node is inaccessible as well.</p> <p>Another disadvantage is the reliance on intermediate nodes for indexing the reply tree. The amount of work (CPU time, network requests, etc.) scales linearly with the size of the reply tree, and more importantly <strong>discoverability of new branches of the reply tree necessitate a re-crawl of the entire reply tree</strong>. For fast-growing trees, this may not net you a complete tree depending on when you begin crawling.</p> <p>Lastly, in the ideal case, a full tree crawl would net you a complete tree with all branches and leaves. Great!</p> <p>Mastodon is the sole implementor of this approach, although it is not proprietary or special to Mastodon by any means.</p> <h2>FEP 7888/f228, or FEP 171b/f228</h2> <p>Summarized by <a href="https://mitra.social/users/silverpill">@<bdi>silverpill@mitra.social</bdi></a> in <a href="https://w3id.org/fep/f228" rel="nofollow ugc">FEP f228</a> (as an extension of FEPs <a href="https://w3id.org/fep/7888" rel="nofollow ugc">7888</a> by <a href="https://mastodon.social/@trwnh">@<bdi>trwnh@mastodon.social</bdi></a> and <a href="https://w3id.org/fep/171b" rel="nofollow ugc">171b</a> by <a href="https://fediversity.site/channel/mikedev">@<bdi>mikedev@fediversity.site</bdi></a>), this conversational backfill approach defines the concept of a "context owner" as referenced by compatible nodes in the tree. This context owner returns an <code>OrderedCollection</code> containing all members of the context.</p> <p>A major advantage of this approach centers around the pseudo-centralization provided by the context owner. This "single source of truth" maintains the index of objects (or activities) and supplies their IDs (or signed full activities) on request. Individual implementations then retrieve the objects (or activities). It is important to note that <strong>should the context owner become inaccessible, then backfill is no longer possible to achieve</strong>. On the other hand, a dead or unresponsive intermediate node will not affect the ability of the downstream nodes to be processed.</p> <p>The context owner is only able to respond with a list of objects/activities that it knows about. This does mean that downstream branches that do not propagate upwards back to the root will not be known to the context owner.</p> <p>Additionally, consumers are also able to query the context owner for an index without needing to crawl the entire reply tree. The ability to de-duplicate objects at this level reduces the overall number of network requests (and CPU time from parsing retrieved objects) required, <strong>making this approach relatively more efficient</strong>.</p> <p>Additional synchronization methods (via id hashsums) could be leveraged to reduce the number of network calls further.</p> <p>A number of implementors follow this approach to backfill, including NodeBB, Discourse, WordPress, Frequency, Mitra, and Streams. Additional implementors like Lemmy and Piefed have expressed interest.</p> <p>One technical hurdle with this approach is technical buy-in from implementors themselves. Unlike crawling a reply tree, this approach only works when the context owner supports it, and thus should be combined with various other backfill strategies as part of an overall conversational backfill solution.</p> <h2>Conclusion</h2> <p>2025 is shaping up to be an exciting year for resolving some of the harder technical and social problems endemic to the open social web/fediverse. It is this author's opinion that we may be able to make good headway towards resolving the "quiet fedi" problem with these two approaches.</p> <p>It is important to note that <strong>neither approach conflicts with the other</strong>. Implementations are free to utilise multiple approaches to backfill a conversation. Both methods presented here have pros and cons, and a combination of both (or more) could be key.</p> <p>Feel free to use this as a starting point for discussions regarding either approach. Does one speak to you more than the other? Are the cons of either approach significant enough for you to disregard it? What other approaches or changes could you recommend?</p>

Read more →
0
0

TrinityNYC:
"現地の住民が皆、LAで「暴動」など起こってないと言ってるのに、ああしてわざと兵力を投入して暴力を煽り、戦争状態を作り上げて挑発し、平和的なプロテストが文字通りの暴動に発展するのを舌なめずりして待ってるんだ。暴動が起これば、戒厳令を発して、楯突く者を一網打尽に逮捕投獄して、他の都市への見せしめにできるからな。" — Bluesky
bsky.app/profile/frankie0320.b

0

alright, i making misskey plugin to change your note to uwu lang

here:

/// @ 0.12.4
### {
  name: "Uwuified",
  version: "1.0.0",
  author: "Misa",
  description: "Change text to UwU~",
  permissions: ["write:notes"]
}

Plugin:register_post_form_action("UwU", @(note, rewrite) {
  let text = note.text

  let text1 = text.replace("r", "w")
  let text2 = text1.replace("l", "w")
  let text3 = text2.replace("na", "nya")

  let result = `{text3} uwu~`

  Mk:dialog("Uwuified!", "UwU~", "success")
  rewrite("text", result)
})
how to use:
1. goes to setting->plugin->install plugin -> paste the code and install
2. make a note
3. click plugin logo on note dialog and choose the plugin
4. enjoy

note: based on the docs, it is only run in client-side

1

just small circles 🕊 shared the below article:

Backfilling Conversations: Two Major Approaches

julian @julian@community.nodebb.org

<p>In February 2025, I presented a topic at FOSDEM in Brussels entitled <a href="https://spectra.video/w/xwCSYfZh1mJY64zJ9GngbE" rel="nofollow ugc">The Fediverse is Quiet — Let's Fix That!</a> In it, I outlined several "hard problems" endemic to the fediverse, focusing on one particular complaint that is often voiced by newcomers and oldtimers alike; that the fediverse is quiet because you don't ever see the full conversation due to some design considerations made at the protocol level.</p> <p>Since then there have been a number of approaches toward solving this problem, and it is worth spending the time to review the two main approaches and their pros and cons.</p> <p><em>N.B. I have a conflict of interest in this subject as I am a proponent of one of the approaches (FEP 7888/f228) outlined below. <strong>This article should be considered an opinion piece.</strong></em></p> <hr /> <h2>Crawling of the reply tree</h2> <p>First discussed 15 April 2024 and merged into Mastodon core on 12 Mar 2025, <a href="https://neuromatch.social/@jonny">@<bdi>jonny@neuromatch.social</bdi></a> pioneered this approach to "fetch all replies" by crawling the entirety of the reply tree. When presented with an object, the Mastodon service would make a call to the <code>context</code> endpoint, and if supported(?) would start to crawl the reply tree via the <code>replies</code> collection, generating a list of statuses to ingest.</p> <p>This approach is advantageous for a number of reasons, most notably that <code>inReplyTo</code> and <code>replies</code> are <strong>properties that are ubiquitous</strong> among nearly all implementations and their usage tends not to differ markedly from one another.</p> <p><em>N.B. I am not certain whether the service would crawl <em>up</em> the <code>inReplyTo</code> chain first, before expanding downwards, or whether <code>context</code> is set in intermediate and leaf nodes that point to the root-level object.</em></p> <p>One disadvantage is this approach's <strong>susceptibility to network fragility</strong>. If a single node in the reply tree is temporarily or permanently inaccessible, then every branch of the reply tree emanating from that node is inaccessible as well.</p> <p>Another disadvantage is the reliance on intermediate nodes for indexing the reply tree. The amount of work (CPU time, network requests, etc.) scales linearly with the size of the reply tree, and more importantly <strong>discoverability of new branches of the reply tree necessitate a re-crawl of the entire reply tree</strong>. For fast-growing trees, this may not net you a complete tree depending on when you begin crawling.</p> <p>Lastly, in the ideal case, a full tree crawl would net you a complete tree with all branches and leaves. Great!</p> <p>Mastodon is the sole implementor of this approach, although it is not proprietary or special to Mastodon by any means.</p> <h2>FEP 7888/f228, or FEP 171b/f228</h2> <p>Summarized by <a href="https://mitra.social/users/silverpill">@<bdi>silverpill@mitra.social</bdi></a> in <a href="https://w3id.org/fep/f228" rel="nofollow ugc">FEP f228</a> (as an extension of FEPs <a href="https://w3id.org/fep/7888" rel="nofollow ugc">7888</a> by <a href="https://mastodon.social/@trwnh">@<bdi>trwnh@mastodon.social</bdi></a> and <a href="https://w3id.org/fep/171b" rel="nofollow ugc">171b</a> by <a href="https://fediversity.site/channel/mikedev">@<bdi>mikedev@fediversity.site</bdi></a>), this conversational backfill approach defines the concept of a "context owner" as referenced by compatible nodes in the tree. This context owner returns an <code>OrderedCollection</code> containing all members of the context.</p> <p>A major advantage of this approach centers around the pseudo-centralization provided by the context owner. This "single source of truth" maintains the index of objects (or activities) and supplies their IDs (or signed full activities) on request. Individual implementations then retrieve the objects (or activities). It is important to note that <strong>should the context owner become inaccessible, then backfill is no longer possible to achieve</strong>. On the other hand, a dead or unresponsive intermediate node will not affect the ability of the downstream nodes to be processed.</p> <p>The context owner is only able to respond with a list of objects/activities that it knows about. This does mean that downstream branches that do not propagate upwards back to the root will not be known to the context owner.</p> <p>Additionally, consumers are also able to query the context owner for an index without needing to crawl the entire reply tree. The ability to de-duplicate objects at this level reduces the overall number of network requests (and CPU time from parsing retrieved objects) required, <strong>making this approach relatively more efficient</strong>.</p> <p>Additional synchronization methods (via id hashsums) could be leveraged to reduce the number of network calls further.</p> <p>A number of implementors follow this approach to backfill, including NodeBB, Discourse, WordPress, Frequency, Mitra, and Streams. Additional implementors like Lemmy and Piefed have expressed interest.</p> <p>One technical hurdle with this approach is technical buy-in from implementors themselves. Unlike crawling a reply tree, this approach only works when the context owner supports it, and thus should be combined with various other backfill strategies as part of an overall conversational backfill solution.</p> <h2>Conclusion</h2> <p>2025 is shaping up to be an exciting year for resolving some of the harder technical and social problems endemic to the open social web/fediverse. It is this author's opinion that we may be able to make good headway towards resolving the "quiet fedi" problem with these two approaches.</p> <p>It is important to note that <strong>neither approach conflicts with the other</strong>. Implementations are free to utilise multiple approaches to backfill a conversation. Both methods presented here have pros and cons, and a combination of both (or more) could be key.</p> <p>Feel free to use this as a starting point for discussions regarding either approach. Does one speak to you more than the other? Are the cons of either approach significant enough for you to disregard it? What other approaches or changes could you recommend?</p>

Read more →
0

日本語で韓国のことを発信しているYouTuberの「きばるん」「デボちゃん」「李ファミリー」の政治系コンテンツは、完全に韓国右派の主張と同じで、自分も害しかないと感じていた

XユーザーのKoki Ito 高麗大学・政治外交学科さん: 「この「可哀想な人」という認識は先の兵庫県知事選でそっくりそのまま斎藤元彦に適用されていた「表現」で偏向した情報が創り出す「世界観の恐怖」にただただ怯えるしかなかった。名指しして申し訳ないが、きばるん・デボちゃんの政治コンテンツは「百害あって一利なし」だと断言しておきたい。」 / X: x.com/_imyour_koki/status/1881

0
1
0
0
0

昨晚有比較早上床,不過還是玩了一會手機才睡
入睡好像比之前的星期日晚上容易,但有覺得比較淺眠
而且鬧鐘響之前一段時間已經醒來無法繼續睡,以至於起來還是跟失眠的時候差不多累

覺得可以加個 的tag :dogsad:

0
1
0
1
0
0
0

@mekkaokerekemekka okereke :verified: I have Cuban relatives in Florida. They are Republican (ofc), identify as white, and feel American. I’ve tried to understand how that works within a society that sees them as brown and inmigrants, but can’t get insights from them. It is very complex.

Also, some of them are diabetics and pay thousands for their insulin (that would cost them zero in my country), but “Democrats are communists and Social Security is a scam”.

It is hard to wrap my euro mind around it :/

0
0
0

So I've run out the end of some of the yuri manga I've been reading and I'm trying to decide whether to start a new yuri or to finish out Kowloon Generic Romance, which is really good. Wait, maybe I've convinced myself I should just keep going with Kowloon Generic Romance

0
0
0
0
0
0