126 Matching Annotations
  1. Last 7 days
    1. The migration would not be complete without calling out that I was unable to build the Mastodon code base on our new primary Puma HTTP server.
  2. Nov 2022
    1. But. I somehow changed-ish laptop, and you know the problem where you change laptop and suddenly you lose access to a few things? Yes. That's one of my problems. This site was using nini to statically generate pages and interconnect them with backlinks, and it's great. But I figured I'll keep it to simple html pages that don't need any compilation for now, so that when I change this laptop, I'll still be able to publish without having to install anything.
    1. This made me realize how little joy I’ve been getting from being an admin. How I’ve come to resent the work I have volunteered to do.
  3. Oct 2022
    1. This costs about $650 USD to operate

      Crazy! This underscores how badly Mastodon—and ActivityPub, generally—need to be revved to enable network participation from low-cost (essentially free) static* sites.

      * quasi-static, really—in the way that RSS-enabled blogs are generally considered static sites

  4. pointersgonewild.files.wordpress.com pointersgonewild.files.wordpress.com
    1. IMO: one of the biggest problems in modern softwaredevelopment• Code breaks constantly, even if it doesn’t change• Huge cause of reliability issues and time wasted• This is somehow accepted as normal

      ⬑ "The Code Rot Problem"

    1. This is the big hurdle; to leap over it you have to be able to create the program text somewhere, compile it successfully, load it, run it, and find out where your output went.
    1. this level oftime commitment is likely to prevent a potential user with apassing interest from trying a programming language or tool
    1. We next made two attempts to buildeach system. This often required edit-ing makefiles and finding and in-stalling specific operating system andcompiler versions, and external librar-ies.
    2. Several hurdles must becleared to replicate computer systemsresearch. Correct versions of sourcecode, input data, operating systems,compilers, and libraries must be avail-able, and the code itself must build
  5. Sep 2022
    1. It's wild that you have to set up Docker to contribute to 600 characters of JavaScript.

      Current revision of README: https://github.com/t-mart/kill-sticky/blob/124a31434fba1d083c9bede8977643b90ad6e75b/README.md

      We're creating a bookmarklet, so our code needs to be minified and URL encoded.

      Run the following the project root directory:

      $ docker build . -t kill-sticky && docker run --rm -it -v $(pwd):/kill-sticky kill-sticky
      
    1. Un-fortunately, there are no ascertainable statistics on the amount of time we wastefussing among papers and mislaying things
    1. Many research projects are publicly available but rarely useddue to the difficulty of building and installing them
    1. Over in the IndieWeb community we were having a conversation about how easy it should be for people to create their own websites (also for small local businesses etc.) Where making the site is basically the same as writing the text you want to put on it. Social media silos do that for you, but out on the open web?
    1. When I go to use some software it takes an inordinate amount of time to set things up.
    2. Some of my ruby, nodejs and python projects no longer run due to dependencies not being pinned at creation time.
  6. Aug 2022
    1. So what’s wrong with all the different languages? Nothing, if you enjoy the mental exercise of creating and/or learning new languages. But usually that’s all they are: a mental exercise.
    1. There has been significant pressure for scientists to make their code open, but this is not enough. Even if I hired the only postdoc who can get the code to work, she might have forgotten the exact details of how an experiment was run. Or she might not know about a critical dependency on an obsolete version of a library.
    1. today’s notebook implementations require note-book authors to take various precautions to ensure repro-ducibility, which are exactly the same as required for makingscripts reproducible: a detailed documentation of the soft-ware environment that was used, listing all dependencieswith detailed version information
    1. over the seven years of the project, I ended upspending a lot of time catching up with dependencies. Newreleases of NumPy and matplotlib made my code collapse,and the increasing complexity of Python installations addedanother dose of instability. When I got a new computer in2013 and installed the then-current versions of everything,some of my scripts no longer worked and, worse, oneof them produced different results. Since then, softwarecollapse has become an increasingly serious issue for mywork. NumPy 1.9 caused the collapse of my MolecularModelling Toolkit, and it seems hardly worth doing muchabout it because the upcoming end of support for Python 2in 2020 will be the final death blow.
    1. even if the code has been made available, it cannotbe easily run because of changes in the underlyinglibraries, operating systems, and other dependen-cies
    2. Finally, software is hard to work with. Forgetmaking research reproducible, it is hard enough touse it 6 months later.
  7. Jul 2022
    1. if you’re a beginner you can use Replit which allows you to program through your browser without installing anything on your machine
    1. We never got there. We never distributed the source code to a working web browser, more importantly, to the web browser that people were actually using. We didn't release the source code to the most-previous-release of Netscape Navigator: instead, we released what we had at the time, which had a number of incomplete features, and lots and lots of bugs.
    1. getting set up requires a github account and “pushing” commits every time I write a post
    2. But starting, hosting and maintaining your own blog is still too hard.
    1. It's also hard to share this workflow with someone non-technical. I have to setup and maintain the correct environment on their machine
    1. It is long past time to return to designing tools not just for rock stars at Google but the vast majority of programmers and laypeople with simple small-scale problems.
    1. @2:10

      They didn't publish the code. They published the algorithm. And they prided themselves on—the computer scientists at the time—of describing the algorithm, not GitHubbing the code. These days we don't—we GitHub the code. You want the algorithm? Here's the code.

      This is not always reliable. There are some non-highly-mathematical things that you'd prefer to have the algorithm explained rather than slog through the code, which is probably adulterated with hacks for e.g. platform gotchas, etc.

      There is a better way, though, which is to publish a high-level description of the workings as runnable code that you can simulate in a Web browser. Too many people have misconceptions about the stability of the Web browser as a platform for simulations, however. We need to work on this.

    1. When you’re building developer tools, if the officially supported developer environment doesn’t work for people in some way, they build their own approach.
    2. it shows that any time that you make something easier or harder to do, either because it’s faster or slower, or just because you’ve reduced the number of steps, or you’ve made the steps more annoying, or you’ve added cognitive overhead, then people react by changing how they use your tool.
    1. @14:18:

      So, for example, if you want to make a very basic static site: well, okay, now you need the static site generator, and now you need a library system, you need a package manager, you need a way to install the package manager, you need a way to check for security vulnerabilities in all the packages, you need a web server, you need a place to run the app. It's a whole thing, right?

    1. It took me an hour to rewrite my ui code and two days to get it to compile. The clojurescript version I started with miscompiles rum. Older clojurescript versions worked with debug builds but failed with optimizations enabled, claiming that cljs.react was not defined despite it being listed in rum's dependencies. I eventually ended up with a combination of versions where compiling using cljs.build.api works but passing the same arguments at the command line doesn't.
  8. Jun 2022
    1. There’s not much implementations can do, and it’s up to the debugger to be smarter about it.

      This is fatalistic thinking.

      Here's what both implementations and debuggers can do together: 1. implementations can document these things 2. debuggers can read the documentation and act accordingly

    1. other people’s toolchains are absolutely inscrutable from the outside. Even getting started is touchy. Last month, I had to install a package manager to install a package manager.
    1. I suspect because most software is optimized for industrial use, not personal use. For industrial uses the operations overhead is not a big deal compared to the development and operational efficiency gained by breaking things up into communicating services. But for personal uses the overwhelming priority is reducing complexity so that nothing fails.
    2. preventing the build from bitrotting would probably require a full-time maintainer in the long run
    1. I was speaking to the CEO of a developer tools company earlier this year. He told me that the biggest obstacle to contribution is his local development environment.
    2. Your personal dev environment travels with you no matter which device you use

      A lot of these ideas are junk. This one, though, is achievable. triplescripts.org.

    1. This negatively impacted our team’s ability to work quickly and efficiently as they improved our documentation.

      Meanwhile, when I reported an error (broken link) in Cloudflare's documentation to a developer there, I was told "I'm sorry that our workflow doesn't work for you, but relaying typo reports through e-mail doesn't scale well on our end," just before snidely signing off with a lame attempt to upperhand: "I guess we'll have to get by without your reports."

    2. Built using Go, Hugo is incredibly fast at building large sites, has an active community, and is easily installable on a variety of operating systems. In our early discovery work, we found that Hugo would build our docs content in mere seconds.
    3. Developer documentation is incredibly important to the success of any product. At Cloudflare, we believe that technical docs are a product – one that we can continue to iterate on, improve, and make more useful for our customers.One of the most effective ways to improve documentation is to make it easier for our writers to contribute to them.
    1. The interconnectivity features need a server though, and that involves either using a third-party service, or spinning up your own VPS, which means added cost, and you’ll probably have to do that at some point anyway if you choose the third-party option at first.
  9. May 2022
    1. I think adding automated deployments would be a nice quality-of-life feature and would definitely encourage me to write more. Currently, I have to upload a new text file to my server and refresh the pm2 job.

      Is "automated deployments" really the solution?

    1. I develop in Node and Sveltekit regularly and the chances that on any given day my flow might be crushed by random madness is unacceptably high.
    2. I have seen experienced developers pull their hair out for a day or more trying to get a basic build system working, or to import a simple module.
    1. This is a problem with all kinds of programming for new learners - actually writing some code is easy. But getting a development environment configured to actually allow you to start writing that code requires a ton of tacit knowledge.
    1. I can write JS and TypeScript easily enough but when I start a new project I'm always fighting the tooling for at least half an hour before I can get going.
    1. Yes, you could write Python utilities that are easy to install and run, but people don't. And the last bit of that sentence is the one that actually counts. "Could have" doesn't actually count in an engineering context.
    1. I just want to try this C++, download, unzip, oh it's windows so .project file. Fine, redo on windows , oh it's 3 versions of vstuido old and says it wants to upgrade , okay. Hmm errors. Try to fix. Now it's getting linking error.
    1. It feels like every example I run into is an easy to follow "20-steps + 10 packages + 64GB cloud server instance" process when all I want to do is to download some historical temperature data to CSV.
    1. if you think it's hard for someone who is already a programmer - think about how needlessly complicated the entire ecosystem and everything surrounding it is for the average person
    1. Today I tried to help a friend who is a great computer scientist, but not a JS person use a JS module he found on Github. Since for the past 6 years my day job is doing usability research & teaching at MIT, I couldn’t help but cringe at the slog that this was. Lo and behold, a pile of unnecessary error conditions, cryptic errors, and lack of proper feedback.
    1. > Movim is easy to deploy> Movim is lightweight (only a few megabytes) and can be deployed on any server. We are providing a Docker image, a Debian package or a simple installation tutorial if you want to deploy it yourself.I imagine a typical Tumblr user landing on this page and not getting a single word of the "easy to deploy" section.

      Related: comments about deployability of PHP over in the comments about "The Demise of the Mildly Dynamic Website".

    1. I woke up realizing one of the computers I use isn't set up to build and I wished I could use it to build and release the new version
    1. The thrill of getting "hello world" on the screen in Symbian/S60 is not something I'll ever forget. Took ages of battling CodeWarrior and I think even a simple app was something like 6 files
    1. I still stick by the fact that web software used to be like: point, click, boom. Now it is like: let's build a circuit board from scratch, make everyone learn a new language, require VPS type hosting, and get the RedBull ready because it's going to take a long time to figure out.
    1. Furthermore, its release philosophy is supposed to avoid what I call “the problem with Python”: your code stops working if you don’t actively keep up with the latest version of the language.
    1. The biggest barriers to coding are technical complexity around processes like collaboration and deployment, and social obstacles like gatekeeping and exclusion — so that's what we've got to fix
    2. If you’re a coder, when’s the last time you just quickly built something to solve a problem for yourself or simply because it was a fun idea?

      And how future-proof was the result or how easy was it to make sure you could share it with others in a form that they could make use of (and not be dependent on you or some third-party or their internet connection)?

    1. That said, I've since realized I was wrong of course. Trying to maintain projects that haven't been touched in more than a year led to hours of fixing dependency issues.
    1. Psst: Philip gave me a copy of this piece (just like he did many others before he decided to unpublish it). I will totally let you peek at my copy (if you want, and if you happen to be in Austin—I'll respect Philip's commandment not to distribute unauthorized copies, but to reiterate: you're free to look at the copy I already have). It's a great article, even if lots of the feedback at the time unnecessarily focused on quibbling with his decision to characterize the issue as being inherent to "command-line bullshittery", rather than charitably* interpreting it as general discontent with the familiar pain** of setting up/configuring/working with any given toolchain and the problems that crop up (esp. when it comes at the price of discouraging smart or even brilliant people who have interesting ideas they wish to pursue.)

      * See also https://pchiusano.github.io/2014-10-11/defensive-writing.html

      ** See also http://lighttable.com/2014/05/16/pain-we-forgot/

    1. Requirements: Ruby and Bundler should be installed.

      wat

      This site has a total of two pages! Just reify them as proper documents instead of compilation artifacts emitted from an SSG.

  10. autonomous-data.noeldemartin.com autonomous-data.noeldemartin.com
    1. Autonomous

      This term is well-suited for the sort of thing I was going for with S4/BYFOB.

      @tomcritchlow's comment about being hobbled by CORS in his attempt to set up an app[1] that is capable of working with his Library JSON is relevant. With a BYFOB "relay" pretty much anyone can get around CORS restrictions (without the intervention of their server administrator). The mechanism of the relay is pretty deserving of the "autonomous" label—perhaps even moreso that Noel's original conception of what Autonomous Data really means...

      1. https://library-json-node-2.tomcritchlow.repl.co/library?url=https://tomcritchlow.com/library.json
    1. Imagine if node.js shipped inside Chrome by default!

      There was something like that, in HTML5's pre-history: Google Gears.

      I've thought for a long time that someone should resurrect it (in spirit, that is) for the world's modern needs. Instead of running around getting everyone to install NodeJS and exhorting them to npm install && npm run, people can install the "Gears 2" browser extension which drastically expands the scope of the browser capabilities, and you can distribute app bundles that get installed "into" Gears.

      Beaker (mentioned later in this post) was an interesting attempt. I followed them for awhile. But its maintainers didn't seem to appreciate the value of frictionless onboarding experience, which could have been made possible by e.g. working to allow people to continue using legacy Web browsers and distributing an optional plug-in, in the vein of what I just described about Gears.

    2. But… on installing node.js you’re greeted with this screen (wtf is user/local/bin in $path?), and left to fire up the command line.

      Agreed. NodeJS is developer tooling. It's well past the time where we should have started packaging up apps/utilities that are written in JS so that they can run directly in* the browser—instead of shamelessly targeting NodeJS's non-standard APIs (on the off-chance everyone in your audience is a technical user and/or already has it installed).

      This is exactly the crusade I've been on (intermittently) when I've had the resources (time/opportunity) to work on it.

      Eliminate implicit step zero from software development. Make your projects' meta-tooling accessible to all potential contributors.

      * And I do mean "in the browser"—not "on a server somewhere that you are able to use your browser to access, à la modern SaaS/PaaS"

    3. An incomplete list of things I’ve tried and failed to do
  11. Apr 2022
    1. the C standard — because that would be tremendously complicated, and tremendously hard to use

      "the C standard [... is] tremendously complicated, and tremendously hard to use [...] full of wrinkles and [...] complex rules"

    1. myvchoicesofwhatto.attemptandxIiwht,not,t)a-ttemptwveredleterni'ine(toaneiiubarma-inohiomlreatextentbyconsidlerationsofclrclfea-sibilitv

      my choices of what to attempt and what not to attempt were determined to an embarrassingly great extent by considerations of clerical feasibility.

    1. Not realizing that you need to remove the roadblocks that prevent you from scaling up the number of unpaid contributors and contributions is like finding a genie and not checking to see if your first wish could be for more wishes.

      Corollary: nobody wants janky project infrastructure to be a roadblack to getting work done. It should not take weeks or days of unrewarded effort in the unfamiliar codebase of a familiar program before a user is confident enough to make changes of their own

      I used to use the phrase 48-hour competency. Kartik says "an hour (or three)". Yesterday I riffed on the idea that "you have 20 seconds to compile". I think all of these are reasonable metrics for a new rubric for software practice.

    1. Most programs today yield insight only after days or weeks of unrewarded effort. I want an hour of reward for an hour (or three) of effort.
    1. must not consist of a bag of tricks and trade secrets, but of a general intellectual ability

      I often think about how many things like Spectre/Meltdown are undiscovered because of how esoteric and unapproachable the associated infrastructure is that might otherwise better allow someone with a solid lead to follow through on their investigation.

    1. When something goes wrong with a computer, you are likely to be stuck. You can't ask the computer what it was doing, why it did it, or what it might be able to do about it. You can report the problem to a programmer, but, typically, that person doesn't have very good ways of finding out what happened either.
    2. Fry's Law states that programming-environment performance doubles once every 18 years, if that.
    1. The difficulty encountered by authors today when they create metadata for hypertexts points to the risk that adaptive hypermedia and the semantic Web will be initiatives that fit only certain, well-defined communities because of the skills involved
  12. Mar 2022
  13. citeseerx.ist.psu.edu citeseerx.ist.psu.edu
    1. Writing for the web is still a complex and technically sophisticated activity. Too many tools, languages, protocols, expectations and requirements have to be considered together for the creation of web pages and sites.
    1. the complexity is not intellectually rich. Substantial coordination between tools is required to perform simple operations. This busywork draws from a finite pool of cognitive resources
    1. front-end dumpster fires, where nothing that is over 18 months old, can build, compile or get support anymore. In my day job, I inherit "fun" tasks as 'get this thing someone glued together with webpack4 and frontend-du-jour to work with webpack5 in 2022
    1. I tried building Firefox once but I wasn't able to, it's slightly outside of my competences at the moment
    1. Don’t read the code before learning to build the project. Too often, I see people get bogged down trying to understand the source code of a project before they’ve learned how to build it. For me, part of that learning process is experimenting and breaking things, and its hard to experiment and break a software project without being able to build it.
    1. I am struggling to think of any open source project of any size beyond small NPM packages that I've experienced that do not have an arcane build system. At least all of the ones I've encountered have been incredibly obtuse, to the point that I've mostly just given up.
    1. having to install 12gb xcode so i can convert my chrome extension to safari. or my local env/build system stop working because i update from catalina to big sur

    Tags

    Annotators

    1. I’m considering updating my Mac to Big Sur just to run this.

      Meanwhile, not only does the scope of this tool not merit the Big Sur requirement, it doesn't even require a Mac. It interaction style is so free of intracies that it could be developed (and distributed) as a single HTML file with a text input and some script blocks.

    1. Around @11:16:

      "What made HyperCard the ubiquitous product it was in the early 90s... was the fact that it was included free with every Macintosh sold. So anybody could use it to create somethnig, then share their creation with somebody else with the confidence that the other person would be able to run it."

      So that was in that day. What is the box today?

      Let me ask it another way: What is available on every computing device[...]?"


      I would encourage us all to find ways to make the system immediately available to users.

    1. You will need a JVM installed with appropriate enviornment settings (JAVA_HOME, etc) along with Maven 2.x+. You will also need Babel as well as SIMILE Butterfly. Butterfly should be installed in a peer directory to Backstage, like
    1. I have been personally and my whole professional life on Linux for 15y. And I have the exact same feeling when I have to compile something.The waste of time to compile anything is staggering. And more often than not I give up on failure after 2h.
    1. Understanding a strange codebase is hard.

      John Nagle is fond of making the observation that there are three fundamental and recurring questions that dominate one's concerns when programming in C.

      More broadly (speaking of software development generally), one of the two big frustrations I have when dealing with a foreign codebase is the simple question, "Where the hell does this type/function come from?" (esp. in C and, unfortunately, in Go, too, since the team didn't take the opportunity to fix it there when they could have...). There's something to be said for Intellisense-like smarts in IDEs, but I think the criticism of IDEs is justified. I shouldn't need an IDE just to be able to make sense of what I'm reading.

      The other big frustration I often have is "Where does the program really start?" Gilad Bracha seems to really get this, from what I've understood of his descriptions about how module definitions work in Newspeak. Even though it's reviled, I think Java was really shrewd about its decisions here (and on the previous problem, too, for that matter—don't know exactly where FooBar comes from? welp, at least you can be reasonably sure that it's in a file called FooBar.java somewhere, so you can do a simple (and cheap) search across file names instead of a (slow, more expensive) full-text search). Except for static initializers, Java classes are just definitions. You don't get to have live code in the top-level scope the way you can with JS or Python or Go. As cumbersome as Java's design decision might feel like it's getting in your way when you're working on your own projects and no matter how much you hate it for making you pay the boilerplate tax, when it comes to diving in to a foreign codebase, it's great when modules are "inert". They don't get to do anything, save for changing the visibility of some symbol (e.g. the FooBar of FooBar.java). If you want to know how a program works, then you can trace the whole thing, in theory, starting from main. That's really convenient when it means you don't have to think about how something might be dependent on a loop in an arbitrary file that immediately executes on import, or any other top-level diddling (i.e. critical functionality obscured by some esoteric global mutable state).

    1. Despite its warts, we continue to rely on e-mail with attachments as the standard enabler of these collaborations because it is a universal solvent. Our HR folks, for example, work for a different organizational unit than I do. Implementing a common collaboration system would require effort. Exploiting the e-mail common denominator requires none.
  14. Feb 2022
    1. The tool uses nodejs and once nodejs is installed, you can install the tool using:
    1. Editing a list of dependencies or wrangling with package managers doesn’t sound too bad

      Disagree. Sounds plenty bad.

  15. Jan 2022
  16. Dec 2021
    1. With that in mind, I'm trying something new, the guided tour for Mu. Ironically, it atomizes my previous docs by linking repeatedly into anchors in the middle of pages. Proceed if you dare.

      The current incarnation of the tutorial (https://raw.githubusercontent.com/akkartik/mu/7195a5e88e7657b380c0b410c8701792a5ebad72/tutorial/index.md) starts by describing "Prerequisites[:] You will need[...]", and then goes on to list several things, including various software packages—assuming a Linux system, etc.

      This is the idea I'm trying to get across with the self-containedness I've been pursuing (if not with triple scripts then at least with LP docs).

      That prerequisites list should be able to replace with two requirements, i.e.:

      "You will need: (1) this document, and (2) the ability to read it (assuming you have an appropriate viewer [which in 2021 is nowhere close to the kind of ask of the old world])"

    1. I do wonder if this will eventually become a burden in the future when Node inevitably falls out of favor.

      "burden"

    2. since when have I enjoyed webpack
    3. looks like I need a full blown Ruby environment. No thanks!
    4. If a piece of software (or a web site) gets in my way, I usually just give up and move on because that first irritation is usually just the first drip of an approaching cascade of frustration.
  17. Oct 2021
    1. Around @0:25:52

      Krouse: Another subset of "shit just works" would be—

      Leung:"No installation required"?

      Krouse: Yeah. "No installation required". [...] as I was just telling you, I spent the last, like... I spent 5 hours over the last two days installing... trying to install software to get something to run. And it's just ridiculous to have to spend hours and hours. If you want to get Xcode to run, it takes— first of all you need a Mac, which is crazy, and then second of all it takes, depending on your internet connection, it could take you a whole day just to get up and running. Why isn't it xcode.com/create?

    1. I no longer know how it works. I don't care to maintain it. It needs big changes to handle something like embedding a Jupyter notebook. And it depends on Python 2.6(!).With hundreds of pages, and its own custom URL layout that I don't want to break, I dread migrating
  18. Sep 2021
    1. Use node.js v10.2.1 (there are specific bugs in each of v8.x, v9.x, v10.0, and v10.3 that each cause telebit to crash)
    1. the ghcjs compiler. But it was a real pain, I Haskell but it's just getting it to install and run and compile, it's just kind of a nightmare
  19. Aug 2021