1,433 Matching Annotations
  1. Mar 2021
    1. Posting an issue on the discussion boards for a three year old game, yesterday, I wasn't holding my breath for a reply. Earlier, this morning, a dev. responded, stating they'd look at fixing it, and it was just a few hours before it were sorted!
    1. Everyone knows friction in software is harmful. But I think we all continually underestimate just how big an influence friction is on what people actually do and use. People don’t write long multi-tweet threads because it’s a good way to post a short essay, they do it because it’s so low friction.

      Friction within software can be a very good thing.

    1. Async is a digital transformation studio that scales teams and their technical experience.

      Test Annotation

    Tags

    Annotators

    URL

    1. Uber::Option implements the pattern of taking an option, such as a proc, instance method name, or static value, and evaluate it at runtime without knowing the option's implementation.
    1. MIT License. Copyright 2020 Rafael França, Carlos Antônio da Silva. Copyright 2009-2019 Plataformatec.
  2. Feb 2021
    1. How do you know if source maps are working correctly? Try adding a syntax error to one of your assets and use the console to debug. Does it show the correct file and source location? Or does it reference the top level application.js file?
    1. Our mission is to allow people to make money via educational efforts and to dedicate the rest of their time to creating great open source products.

      What does this mean exactly? "Our mission is to allow people to make money via educational efforts"

    1. provide interfaces so you don’t have to think about them

      Question to myself: Is not having to think about it actually a good goal to have? Is it at odds with making intentional/well-considered decisions?  Obviously there are still many of interesting decisions to make even when using a framework that provides conventions and standardization and makes some decisions for you...

    2. Trailblazer is an architectural pattern that comes with Ruby libraries to implement that pattern.
    3. Whether this is the life-cycle of a <user> entity or just a sign-up function, it has to be defined and coded somewhere.
    1. I started Trailblazer GmbH 4 years ago with my relocation from Australia back to Europe. One of our consulting clients is the central police department of a German state that has kept me busy for more than three years now.
    2. We’re now relaunching PRO, but instead of a paid chat and (never existing) paid documentation, your team gets access to paid gems, our visual editor for workflows, and a commercial license.
    3. And yes, at TRB GmbH, we do pay people to work on OSS
    4. To tell you the truth, the new tracing feature was the original reason why I decided to write 2.1 and make you sit and wait in agony for years. Nevertheless, tracing is simply blowing my mind. I can’t count how many hours and angering rushs of adrenaline I’ve saved since the introduction of the wtf? method and its helpful higher-level stack trace.
    5. There is nothing wrong with building your own “service layer”, and many companies have left the Traiblazer track in the past years due to problems they had and that we think we now fixed.
    1. Software architecture is about making fundamental structural choices that are costly to change once implemented.
    2. Software architecture refers to the fundamental structures of a software system
    3. Software architecture choices include specific structural options from possibilities in the design of the software.
    1. A free cultural work (free content) is, according to the definition of Free Cultural Works, one that has no significant legal restriction on people's freedom to:
    1. note that TRB source code modifications are not proprietary

      In other words, you can build on this software in your proprietary software but can't change the Trailblazer source unless you're willing to contribute it back.

      loophole: I wonder if this will actually just push people to move their code -- which at the core is/would be a direction modification to the source code - out to a separate module. That's so easy to do with Ruby, so this restriction hardly seems like it would have any effect on encouraging contributions.

    2. Why is TRB licensed under LGPL, not MIT?
    3. The LGPL allows users to use and integrate LGPL software components into their own software without being required to release the source code of their own software components. However, if users modify LGPL software components (“derivative work”), they are required to make the modified software component available under the same LGPL license. To avoid the latter with TRB, users have to comply with para. 5 LGPLv2.1: A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a “work that uses the Library”. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. In other words: if you use the TRB libraries in your commercial applications or Open-Source projects, you’re not creating a derivative work of Trailblazer. Your software can be distributed under any terms.
    4. Trailblazer (TRB) is an Open-Source project. Since we want to keep it that way, we decided to raise awareness for the “cost” of our work - providing new versions and features is incredibly time-consuming for us, but we love what we do.
    5. This creates a win-win situation, you as the user have your peace of mind, and we can continue working with your funds.
    1. Trailblazer extends the conventional MVC stack in Rails. Keep in mind that adding layers doesn't necessarily mean adding more code and complexity. The opposite is the case: Controller, view and model become lean endpoints for HTTP, rendering and persistence. Redundant code gets eliminated by putting very little application code into the right layer.
    2. Trailblazer offers you a new, more intuitive file layout in applications.
    3. Instead of grouping by technology, classes and views are structured by concept, and then by technology. A concept can relate to a model, or can be a completely abstract concern such as invoicing.
    4. While Trailblazer offers you abstraction layers for all aspects of Ruby On Rails, it does not missionize you. Wherever you want, you may fall back to the "Rails Way" with fat models, monolithic controllers, global helpers, etc. This is not a bad thing, but allows you to step-wise introduce Trailblazer's encapsulation in your app without having to rewrite it.
    1. ActiveInteraction plays nicely with Rails. You can use interactions to handle your business logic instead of models or controllers.
    2. Why is all this interaction code better? Two reasons: One, you can reuse the FindAccount interaction in other places, like your API controller or a Resque task. And two, if you want to change how accounts are found, you only have to change one place.

      Pretty weak arguments though...

      1. We could just as easily used a plain object or module to extract this for easy reuse and having it in only one place (avoiding duplication).
    1. @adisos if reform-rails will not match, I suggest to use: https://github.com/orgsync/active_interaction I've switched to it after reform-rails as it was not fully detached from the activerecord, code is a bit hacky and complex to modify, and in overall reform not so flexible as active_interaction. It has multiple params as well: https://github.com/orgsync/active_interaction/blob/master/spec/active_interaction/modules/input_processor_spec.rb#L41

      I'm not sure what he meant by:

      fully detached from the activerecord I didn't think it was tied to ActiveRecord.

      But I definitely agree with:

      code is a bit hacky and complex to modify

    1. We could quite easily create a model class that isn’t based on ActiveRecord and have it work as Rails is quite decoupled from ActiveRecord, but there are advantages to keeping our model class inheriting from ActiveRecord.
    1. I think a better, more immediately understandable name for this concept would be command object, because it lets you pass around commands (or a list of commands) as objects.

      That's the only thing you really need to know abut this pattern. The rest seems like boring implementation details that aren't that important, and that naturally follow from the primary definition above.

    1. With the introduction of CPUs which ran faster than the original 4.77 MHz Intel 8088 used in the IBM Personal Computer, programs which relied on the CPU's frequency for timing were executing faster than intended. Games in particular were often rendered unplayable. To provide some compatibility, the "turbo" button was added. Engaging turbo mode slows the system down to a state compatible with original 8086/8088 chips.
    1. Great thanks to Blake Education for giving us the freedom and time to develop this project in 2013 while working on their project.
    1. NO support whatsoever will be given for the moment unless I gave you the program personally. This is because all of this is work in progress and I can't code while constantly writing documentation and answering questions.
    1. As of today, you can Wishlist OpenTTD on SteamE. Historically, OpenTTD always had a single home from where we distributed the game. We used to be hosted on SourceForge (you know you are old, if you remember that being a thing :D), and slowly moved towards our own self-created distribution methods. These days, we mostly distribute our game via our website. But times are changing, and so is our hair. Over the last few months, we have silently been working to become a bit more visible in the world. Don’t worry, not for reasons you might think: OpenTTD has as many active users as it had in 2007. But more because we no longer think it is the right approach to only distribute via our own website.
    1. As of today, you can Wishlist OpenTTD on SteamE. Historically, OpenTTD always had a single home from where we distributed the game. We used to be hosted on SourceForge (you know you are old, if you remember that being a thing :D), and slowly moved towards our own self-created distribution methods. These days, we mostly distribute our game via our website. But times are changing, and so is our hair. Over the last few months, we have silently been working to become a bit more visible in the world. Don’t worry, not for reasons you might think: OpenTTD has as many active users as it had in 2007. But more because we no longer think it is the right approach to only distribute via our own website. This became painfully apparent when we noticed other people post OpenTTD on some stores. They are not always updated with new releases, sometimes even slacking behind a few years. And maybe more important to us: we can not guarantee that the uploaded version is unmodified and is the version as we intended. So, instead of fighting it, why not turn around and join them! Why not release our own, verified, builds on those stores! And this is exactly what we have been working on lately. And when I say “we”, a bit ironic to me, I mean the two developers that are around longest (myself and orudge) ;) A while back orudge added OpenTTD to the Microsoft Store. And today, I am happy to announce we will be on SteamE too! Well, we are on Steam, but we haven’t released anything there yet (sorry that I got your hopes up, just to squash them right after :( ). This is partially because of how Steam works, but also because we know we can bring a better experience for Steam with our upcoming release. That brings me to the most exciting news: if everything goes as planned, we will release OpenTTD 1.11 on Steam on the first of April, 2021! And that is not even an April fools’ joke! You can already Wishlist OpenTTD today .. and till we release on Steam, you can find our game via our website ;)
    1. There’s only one hard thing in Computer Science: human communication. The most complex part of cache invalidation is figuring out what the heck people mean with the word cache. Once you get that sorted out, the rest is not that complicated; the tools are out there, and they’re pretty good.
    1. “Functional programming language” is not a clearly defined term. From the various properties that are typically associated with functional programming I only want to focus on one: “Immutability” and referential transparency.

      I mean not clearly defined seems wrong, there are common accepted characteristics that make a language functional.

    1. This gives them a slight edge but that’s nothing substantial because those fixes eventually reach Ubuntu.
    1. But all of these attempts misunderstand why the Open Source ecosystem is successful as a whole. The ecosystem of fairly standard licenses provides a level playing field that allows collaboration with low friction, and produces massive value for everyone involved – both to those that contribute and to those that don't. It is not without problems (there are many essential but unsexy projects that are struggling with funding), but introducing more friction won't improve the success of this ecosystem – it will just lead to some parts of the ecosystem to break off.
    2. Part of me thinks that open source can be more rewarding to the creators/contributors. But maybe the real contribution is the permanent addition to the tools available to humanity, and if you have the wits, you can make a decent business out of it without tainting open source.
    3. Selling proprietary software is difficult when there is so much gratis Open Source software around.
    4. For a sufficiently successful and industry-relevant open source project, it's possible for the main developers to earn a living e.g. by selling related consulting services.
    5. It turns out that creating and using Free Software is not just good to individuals, but for businesses as well, for example by building upon publicly available components and by collaborating shared software. The term Open Source is a business-friendly rebranding of the Free Software concept. This line of thought was also widely successful, e.g. Firefox/Mozilla was an open sourcing of Netscape software.
  3. Jan 2021
    1. Unfortunately, this probably means a death knoll for this gem, at least I predict it will contribute to its slow trajectory towards insignificance/unknownness/lack-of-users.

      Why? Because it is already the less popular option in this comparison: https://ruby.libhunt.com/compare-premailer-rails-vs-roadie-rails

      and being actively maintained is an important factor in evaluating competing options.

      So of course people will see that the premailer option is the option that is still actively maintained, is still continuing to be improved, and they'll see that this one has been relegated to dormancy/stagnancy/neglect/staleness, which will only amplify the degree/sense of abandonment it already has from its maintainer (only now it will be its users that start to abandon it, as I now have).

    2. At work, I cannot maintain this project. At home, I'd rather spend time with my children and on projects that I'm currently passionate about.
    3. Maintaining open source software requires energy and a "want"/"passion". I've not been using this project myself for years, and I mainly work in other things than Rails at this point. That means I'm far removed from this project and see no personal gain in maintaining the energy to keep this going.
    1. Augmented Steam is an open source project. You can verify the code for yourself, help us improve it or create your very own version.
    1. It is pretty much what Ubuntu 20.04 could have been, but isn't.
    2. Flatpak as a truly cross-distro application solution that works equally well and non-problematic for all
    3. It appears that Canonical is continuing it's vice grip of unliateral, maybe dictatorial control on the development of Snap to the benefit of Ubuntu, but to the detriment of groups like Linuxmint, and all other non-Ubuntu based Linux distributions - like CentOS/Redhat, Suse/openSuSe, Solus, Arch/Manjaro, PCLinuxOS, etc, that are pushing Flatpak as a truly cross-distro application solution that works equally well and non-problematic for all. .
    4. If upstream code presumes things will work that dont in snap (e.g. accesses /tmp or /etc) the snap maintainer has to rewrite that code and maintain a fork. Pointless work. Packaging for .deb is a no-brainer.
    5. >Linux needs an app delivery format Yeah, it's incredible that it has managed to survive for so long without one.
    6. It's Snap that drove me to Arch, so it did me a huge favour. Seeing things like GNOME as a snap and other 'core' products wasn't something I was comfortable with. Personally, I prefer flatpaks as a packaging format when compared to snap and appimage. I agree that Linux needs an app delivery format, but snap's current implementation isn't it.
    7. I run a fairly ancient RedHat Enterprise 6 on my 32-bit test machine and if I need something requiring Gtk3 (such as a latest Firefox or Chrome), I just make a chroot and use debootstrap (from EPEL) to get me a Debian 9 userland for that program. Easy. No bizarre "app stores", no conflicting packages. Do people use Snap app-stores because they don't know how to use the chroot command? Or are they just lazy? If it is because they want the added security of a container, substitute chroot with lxc... Shouldn't be necessary though; if you avoid non-ethical software (i.e App-stores), you are very unlikely to need the added security.
    8. Well, that user can safely stay with Windows. Hiding these things from me makes wish that.
    1. Volkswagen, the world’s largest car maker, has outspent all rivals in a global bid by auto incumbents to beat Tesla. For years, industry leaders and analysts pointed to the German company as evidence that, once unleashed, the old guard’s raw financial power paired with decades of engineering excellence would make short work of Elon Musk’s scrappy startup. What they didn’t consider: Electric vehicles are more about software than hardware. And producing exquisitely engineered gas-powered cars doesn’t translate into coding savvy.

      Many thought Volkswagen would crush Tesla as soon as they put their weight behind an electric car initiative. What they didn't consider was that an electric car is more about software than it is about hardware.

    1. If anyone needs this functionality, I've made a primitive approach to forward all standard UI events, plus any others you specify: https://github.com/hperrin/svelte-material-ui/blob/273ded17c978ece3dd87f32a58dd9839e5c61325/components/forwardEvents.js
    1. Would you work for free? It is a simple but loaded question that requires additional context. Is it working to help a friend do something? Is it work that you would enjoy? Does the act of working for free give you some level of satisfaction? Your gut reaction to the question may have been a hearty, “No,” but many people volunteer for a variety of things all the time, so people will work for free when there is something in it they enjoy.
    2. Open source is fundamentally good with the transparency and flexibility it brings; however, as our reliance on it goes up, the overall investment back into the ecosystem has not. It can be easy to take for granted the time and effort many developers put into open source projects. Yet it is with their time and effort that we often save our own.
    3. These developers are not greedy or selfish for wanting funding for their projects. To the contrary, they want funding to keep the project alive. A person has to eat, after all. Funding the project is a means of changing the maintainer’s timeshare—allowing themselves to put time into the project that otherwise would be used for other employment. There is only so much time in a day that a person can otherwise give.
    4. Funding should not be a struggle for open source projects. We embrace open source into our codebases frequently but have yet to fully embrace the idea that funding it actually helps us too. The bug fixes and feature requests need to be implemented, tested, and reviewed by someone who themselves can only put so much time into the project.
    5. While the code may live online somewhere forever, an open source project only truly survives if someone maintains it.
    1. All right, whoever, who wanted to get the latest Chromium work without worrying about snaps, get it from here 15, unzip it and make a executable link to executive file “chrome” in it. It opens instantaneously (in a snap). This Chromium web browser is NOT installed, but lives in a folder called chrome-linux.
    2. Look at it from another distro point of view, like Fedora or Arch. On the whole packages for popular software are not made for those distros - by the manufacturers of the software. As a result many flatpaks and some AUR packages are built by ripping apart debs and re-packing them as other package formats. This benefits Arch and Fedora (and other distros) because they now have access to software they might not have.
    3. While the very same software might be in a PPA and a snap, the fact that the snap is shown in Ubuntu Software is the point I’m making. Many people use that to install software. So making software appear there is beneficial for developers - their software is found, and beneficial for users - they discover new software.
    4. Most users frankly don’t care how software is packaged. They don’t understand the difference between deb / rpm / flatpak / snap. They just want a button that installs Spotify so they can listen to their music.
    5. In addition, PPAs are awful for software discovery. Average users have no idea what a PPA is, nor how to configure or install software from it. Part of the point of snap is to make software discovery easier. We can put new software in the “Editor’s Picks” in Ubuntu Software then people will discover and install it. Having software in a random PPA somewhere online is only usable by experts. Normal users have no visibility to it.
    6. Frankly, if the Ubuntu Desktop team “switch” from making a deb of Chromium to making a snap, I doubt they’d switch back. It’s a tremendous amount of work for developer(s) to maintain numerous debs across all supported releases. Maintaining a single snap is just practically and financially more sensible.
    7. Just saying “snaps are slow” is not helpful to anyone. Because frankly, they’re not. Some might be, but others aren’t. Using blanket statements which are wildly inaccurate will not help your argument. Bring data to the discussion, not hearsay or hyperbole.
    8. Progress is made of compromises, this implies that we have to consider not only disadvantages, but also the advantages. Advantages do very clearly outweigh disadvantages. This doesn’t mean it perfect, or that work shouldn’t continue to minimize and reduce the disadvantages, but just considering disadvantages is not the correct way.
    9. but that doesn’t mean that confining applications is not a benefit also to FOSS applications, security is an issue that needs to be addressed with many layers of measures no mater what licensing approach you use to license the software
    10. However there’s more benefit of confining proprietary closed source applications, because they are to audit to the same level
    11. I don’t think he implies that, he didn’t mentioned FOSS or non-FOSS. Third party doesn’t refer to licensing, only to who provides it.
    12. I don’t find the software slow, I find the startup time for snap packages when the start for the first time on a session slow, but that has been improved, and it’s public that the snapcraft team has been working hard to improve that.
    13. The benefits for developers do reflect on benefits for users, with more software delivered faster and more securely.
    14. wouldn’t that « lesser » the FOSS effort towards desktop app’s ?
    15. Snap gets rid of dependency mess. Good. Snap offers in one place FOSS and proprietary app’s. Here I am suspicious. It may be an advantage for a commercial app-store and for some users. But this advantage may lead to loss of comfort and flexibility for the many users that rely first on FOSS.
    1. If you’re not a huge fan of Snap packages, but love using Ubuntu, this guide is for you. In it, we’ll go over how you can remove Snap from your Ubuntu system and make it so that your system will no longer have access to the Snap store or anything like that.
    2. Snap packages are quickly becoming the primary way that Ubuntu users consume software. Despite Snaps dominating Ubuntu, many users still opt to avoid Snap packages in favor of Apt packages that have long been available in Ubuntu.
    1. If it is powerful and reliable, that means it serves them better.

      software is often oriented towards performance as primary (if not only) criterium, it is developed through a performance-centric lens.

      other cultural, social, ethical factors are ignored or not taken into account

    1. Font Awesome is fully open source and is GPL friendly. You can use it for commercial projects, open source projects, or really just about whatever you want.
    1. artificial intelligence seems to be the future of software

      Is this because AI will write the software? At some point the programmes (and data they need) will be too complex for human beings to understand.

  4. Dec 2020
    1. Therefore, it could be argued that belief regarding the usefulness of technologies could lead to change and ultimately the actual use of digital technologies in teaching and learning.

      This goes both ways. A teacher who believes that their job is to control access to specialised information, and to control assessment may use technology to close down learning opportunities (e.g. by banning the use of Wikipedia, YouTube, etc.) and even insisting on the installation of surveillance (proctoring) software on students' personal computers.

      Again, you can argue that technology in itself doesn't make the difference.

    1. You can also purchase a Nextcould hosting service, which on one hand may not seem any different from giving your photos over to Google or Apple, but there's a significant difference: Nextcloud storage is demonstrably encrypted, with source code to prove it.
    1. We are unapologetic tinkerers who neither invent the wheel, nor are satisfied with the wheels already at our disposal. The best scholarship and the best pedagogy take the best of what already exists and make it better, at least better for the task at hand. We need to embrace this identity as hackers, acknowledge our indebtedness to those who have gone before us, forsake the illusion that we are creating (can create, should create) something wholly original, but also refuse to take for granted the things that have been passed down to us.

      I think that this might be where I'm missing something. The article is about the relationship between open-source software development and scholarship, but now we're talking about "hacking" as the equivalent of a software developer. And I'm not sure that I agree with this.

      I don't think that software-developers think of themselves as hackers. For me, there's an underlying subversive nature in the hacker category, which need not be present in a software developer. There's a conflation between software developer and hacker, which misses some of the nuance that's necessary.

    1. We usually only see people launching projects once they're already done. I'm sure there are countless more unfinished and unlaunched side projects that the world will never know about. Don't let your side project become one of them.
    1. Some devs prefer Svelte’s minimal approach that defers problems to userland, encouraging more innovation, choice, and fragmentation, and other devs prefer a more fully integrated toolkit with a well-supported happy path.

      tag?: what scope of provided features / recommended happy path is needed?

    2. The template language's restrictions compared to JavaScript/JSX-built views are part of Svelte's performance story. It's able to optimize things ahead of time that are impossible with dynamic code because of the constraints. Here's a couple tweets from the author about that
    1. Keep in mind that as a software developer, of any degree, learning is continuous. New technologies, new ways to write code, not so new approaches, persisting patterns. Read books, watch online courses, follow tutorials, keep learning!
    1. Because Jamstack projects don’t rely on server-side code, they can be distributed instead of living on a single server. Serving directly from a CDN unlocks speeds and performance that can’t be beat. The more of your app you can push to the edge, the better the user experience.
    1. Better PerformanceWhy wait for pages to build on the fly when you can generate them at deploy time? When it comes to minimizing the time to first byte, nothing beats pre-built files served over a CDN.
    1. Better contribution workflow: We will be using GitHub’s contribution tools and features, essentially moving MDN from a Wiki model to a pull request (PR) model. This is so much better for contribution, allowing for intelligent linting, mass edits, and inclusion of MDN docs in whatever workflows you want to add it to (you can edit MDN source files directly in your favorite code editor).
  5. Nov 2020
    1. Micro is a platform for cloud native development. It addresses the key requirements for building services in the cloud. Micro leverages the microservices architecture pattern and provides a set of services which act as the building blocks of a platform. Micro deals with the complexity of distributed systems and provides simpler programmable abstractions to build on.

      What they are doing is like AWS lambda - BUT - they abstract away the details of things like Auth, pub/sub, config, networks AND the DB (which is a KV store).

      So you simply write your services letting the platform take care of the particulars of adjacencies.

    1. A Comprehensive Guide on the Dedicated Team Model: Explaining the Concept, Advantages, and Pitfalls

      Take a look at this detailed article by Cleveroad explaining what is dedicated team model.

    1. There are actually 3 other libraries that implements material in svelte, i hope this to become the community favorite because using MDC underneath it implements correctly Material guidelines.
    2. I'm still deeply working on it every day, i'm around 1/2 month away for a first preview release.
    3. from my point of view, it is (by far) the best way, to build a layer on top https://github.com/material-components/material-components-web . This is also the path that the Angular Material team has taken, although they have already made a huge effort to create the components themselves.
    4. @monkeythedev can your work be used already? I would suggest not yet, i'm still doing core changes every day
    1. Portable... your .name address works with any email or web service. With our automatic forwarding service on third level domains, you can change email accounts, your ISP, or your job without changing your email address. Any mail sent to your .name address arrives in any email box you choose.
    1. It is impossible to rebuild the base from the Dockerfile as the 3rd party dependencies have changed significantly since 8 months ago when the base was last built. The tags for my base image have been overwritten and I can only restore them from a descendant image. With Docker 1.8 I simply pulled the descendant image, tagged the base layer and I was done. With Docker 1.10+ I'd need to save, then manually construct the base image descriptor and reload it. Doable but sad that it's far more complex.
    2. Allowing parent layer metadata to be saved for a layer, regardless if the parent layer is in the save command, would be a huge win for those of us working on CI/remote systems. Reusing parent layers used to be ridiculously easy. It would be good if we could get some comparably easy way to do it now.
    3. It used to be great that I was able to select a layer from any image and use it as a starting point. Currently, I am given an image that has 4 layers to be stripped off to get to the original base image. The original image is not reconstructable in any other way.