Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

"I'm a programmer with a Fediverse account.

Uncategorized
4 2 17

Gli ultimi otto messaggi ricevuti dalla Federazione
  • @leogaggl Hey, Leo. Demilitarization of Palestine has been one of the demands of Israeli negotiators since Oslo.

    https://en.wikipedia.org/wiki/Israeli%E2%80%93Palestinian_peace_process

    The US Senate is currently considering a bill to recognize a "demilitarized Palestine":

    https://www.congress.gov/bill/119th-congress/senate-resolution/410/text

    The Trump Gaza plan also specifies that Gaza will be demilitarized:

    https://en.wikipedia.org/wiki/Gaza_peace_plan

    I don't think it's naive to ask if people think Palestine should be demilitarized.

    read more

  • @evan I do enjoy your polls normally. But this one is incredibly naive. To put it mildly.

    If you would have said 'Should the Middle East be demilitarised?' - that would have been reasonable.

    read more

  • @stags ah, ok, helpful!

    read more

  • @evan The gist is: the Hebrew-speaking community on X is very 'social' and focused on the language and culture more than on particular topics or hashtags.

    This means that one would need to individually track down and follow each Hebrew speaker in that community to maintain the connection.

    So when X became really bad, most Hebrew-speaking migrants moved to the only Hebrew-speaking server at the time. Which functionally killed it. - It had to scale up to expensive IT to handle the new load.

    read more

  • @alttexthalloffame @ChasMusic I’m not certain but this may have been a result of the new CSS theme tokens work, rather than a standalone change. I can ask the team tomorrow.

    read more

  • Retrotechtacular: The $550K Video Conferencing System Used to Make Bee Movie

    The modern office environment has shifted in recent years. Employees are routinely asked to collaborate with co-workers half way around the globe and be camera ready, or whatever passes for webcam ready, in order to telecommute when they are out of office. Every office laptop, tablet, or cell phone these days comes equipped with some sort of camera sensor capable of recording at HD resolution. Twenty years ago, that was not the case. Though tech conglomerates like HP had a different idea of teleconferencing to sell back in 2005 dubbed the Halo Collaboration Studio.

    The Halo Studio was a collaboration between HP and Dreamworks that was used during the production of Bee Movie. Studio heads at Dreamworks thought it necessary to install the HP teleconferencing solution inside the New York office of Jerry Seinfeld, the writer of the film, as to allow him to avoid long trips to Dreamworks production offices in Los Angeles. According to the HP Halo Collaboration Studio brochure, “Halo actually pays for itself, not only by reducing travel costs, but also by encouraging higher productivity and stronger employee loyalty.” Certainly Dreamworks believed in that sales pitch for Bee Movie, because the upfront asking price left a bit of a sting.

    Less of a singular machine, more of an entire dedicated room, the Halo Studio had a $550,000 asking price. It utilized three 1280×960 resolution plasma screens each fitted with a 720p broadcast camera and even included an “executive” table for six. The room lighting solution was also part of the package as the intent was to have all participants appear true to life size on the monitors. The system ran on a dedicated T3 fiber optic connection rated at 45 Mbps that connected to the proprietary Halo Video Exchange Network that gave customers access to 24×7 tech support for the small sum of $30,000 a month.

    For more Retrotechtacular stories, check out Dan’s post on the Surveyor 1 documentary. It’s out of this world.

    youtube.com/embed/0E9iKKTiMSA?…

    hackaday.com/2025/11/30/retrot…

    read more

  • @lcruggeri non trovo più lo screenshot, una volta Linux me l'ha mostrato senza ritegno 🤣

    read more

  • @ChasMusic I do not, but I hope @andypiper doesn't mind being paged!

    read more
Post suggeriti
  • Are you still trying to free Palestine?

    Uncategorized evanpoll poll
    1
    0 Votes
    1 Posts
    10 Views
    Are you still trying to free Palestine?#EvanPoll #poll
  • 0 Votes
    1 Posts
    16 Views
    Daylight Savings Time (DST) in the twenty-first century, yay or nay? Please consider boosting for a more statistically significant result. #daylightsavingstime #dst #us #poll #autumn
  • 0 Votes
    3 Posts
    12 Views
    Summary of A Philosophy of Software Design by John Ousterhout Source: danlebrero.com These are notes by Daniel Lebrero Berna on John Ousterhout’s A Philosophy of Software Design. Some advice in the book goes against the current software dogma. The current dogma is the result of previous pains, but has now been taken to the extreme, causing new pains. What the author solves with “Comment-First Development,” others solve with Test-Driven Development. The excuses for not writing comments mirror those for not writing tests. Key Insights It’s easier to see design problems in someone else’s code than your own. Total complexity = Σ(complexity of part × time spent on that part). Goal of good design: make the system obvious. Complexity accumulates incrementally, making it hard to remove. Adopt a “zero tolerance” philosophy. Better modules: interface much simpler than implementation (Deep modules). Design modules around required knowledge, not task order. Adjacent layers with similar abstractions are a red flag. Prioritize simple interfaces over simple implementations. Each method should do one thing and do it completely. Long methods are fine if the signature is simple and the code easy to read. Difficulty naming a method may indicate unclear design. Comments should add precision or intuition. If you aren’t improving the design when changing code, you’re probably making it worse. Comments belong in the code, not commit logs. Poor designers spend most of their time chasing bugs in brittle code. Preface The most fundamental problem in computer science is problem decomposition. The book is an opinion piece. The goal: reduce complexity. 1. Introduction (It’s All About Complexity) Fight complexity by simplifying and encapsulating it in modules. Software design is never finished. Design flaws are easier to see in others’ code. 2. The Nature of Complexity Complexity = what makes code hard to understand or modify. Total complexity depends on time spent in each part. Complexity is more obvious to readers than writers. Symptoms: change amplification, cognitive load, unknown unknowns. Causes: dependencies, obscurity. Complexity accumulates incrementally; remove it aggressively. 3. Working Code Isn’t Enough Distinguish tactical (short-term) from strategic (long-term) programming. The “tactical tornado” writes lots of code fast but increases complexity. 4. Modules Should Be Deep A module = interface + implementation. Deep modules have simple interfaces, complex implementations. Interface = what clients must know (formal + informal). Avoid “classitis”: too many small classes increase system complexity. Interfaces should make the common case simple. 5. Information Hiding (and Leakage) Information hiding is key to deep modules. Avoid temporal decomposition (ordering-based design). Larger classes can improve information hiding. 6. General-Purpose Modules Are Deeper Make modules somewhat general-purpose. Implementation fits current needs; interface supports future reuse. Questions to balance generality: What is the simplest interface covering current needs? How many times will it be used? Is the API simple for current use? If not, it’s too general. 7. Different Layer, Different Abstraction Adjacent layers with similar abstractions are a red flag. Pass-through methods and variables add no value. Fix pass-throughs by grouping related data or using shared/context objects. 8. Pull Complexity Downwards Prefer simple interfaces over simple implementations. Push complexity into lower layers. Avoid configuration parameters; compute reasonable defaults automatically. 9. Better Together or Better Apart? Combine elements when they: Share information. Are used together. Overlap conceptually. Simplify interfaces or eliminate duplication. Developers often split methods too much. Methods can be long if they are cohesive and clear. Red flag: one component requires understanding another’s implementation. 10. Define Errors Out of Existence Exception handling increases complexity. Reduce exception points by: Designing APIs that eliminate exceptional cases. Handling exceptions at low levels. Aggregating exceptions into a common type. Crashing when appropriate. 11. Design It Twice Explore at least two radically different designs before choosing. 12. Why Write Comments? The Four Excuses Writing comments improves design and can be enjoyable. Excuses: “Good code is self-documenting.” False. “No time to write comments.” It’s an investment. “Comments get outdated.” Update them. “Comments are worthless.” Learn to write better ones. 13. Comments Should Describe Things That Aren’t Obvious Comments should add precision and intuition. Document both interface and implementation. 14. Choosing Names Names should be precise and consistent. If naming is hard, the design likely isn’t clean. 15. Write the Comment First Like TDD, comment-first helps design, pacing, and clarity. 16. Modifying Existing Code Always improve design when changing code. Comments belong in code, not commit logs. 17. Consistency Don’t “improve” existing conventions without strong reason. 19. Software Trends Agile and TDD often promote tactical programming. 20. Designing for Performance Simpler code tends to be faster. Design around the critical path. 21. Conclusion Poor designers spend their time debugging brittle systems.
  • 🗾 🌺 😯 😪 #emoji #poll

    Uncategorized emoji poll
    1
    0 Votes
    1 Posts
    13 Views
    🗾 🌺 😯 😪 #emoji #poll