644 Matching Annotations
  1. Last 7 days
  2. Oct 2020
    1. Las grandes compañías de tecnología nos ofrecen productos de gran calidad, aparentemente sin solicitar nada a cambios, más allá del altruismo tecnológico. Esto, de la misma forma en que un banco nos solicita un peso por cada transacción que hagamos a través de sus sistemas.

      Es tan sutil el precio que pagamos que para muchos pasa desapercibido, sin embargo, estás empresas han sabido masificar el cobro sutil que nos hacen. Nuestra información y las cosas que hacemos en internet no deberían ser el precio que nos cobren. Utilizar software que permita una verdadera libertad es importante. Sin embargo, estas grandes empresas tecnológicas han castrado la capacidad exploratoria natural del ser humano para aprender nuevas formas de trabajar en internet y con este tipo de aplicaciones.

    1. To silence circular dependencies warnings for let's say moment library use: // rollup.config.js import path from 'path' const onwarn = warning => { // Silence circular dependency warning for moment package if ( warning.code === 'CIRCULAR_DEPENDENCY' && !warning.importer.indexOf(path.normalize('node_modules/moment/src/lib/')) ) { return } console.warn(`(!) ${warning.message}`) }
    2. Yeah I see what you're saying. In my case, I had a group of classes that relied on each other but they were all part of one conceptual "module" so I made a new file that imports and exposes all of them. In that new file I put the imports in the right order and made sure no code accesses the classes except through the new interface.
    1. The flipped meeting — pioneered by innovative companies like Amazon and LinkedIn, and built on the model of the flipped classroom that has been rolled out in universities across the country and around the world.  Flipping your meetings can help you win back time wasted in meetings, ensure that every meeting you attend is productive, and empower your teams to collaboratively make smarter, timelier decisions. See how, in our complete guide to flipping your meetings.
    1. But there is an alternative. The “flipped meeting” approach is revolutionary in its simplicity: Share the informational presentation before the meeting so participants are fully informed up front Focus the meeting on making decisions, opening discussion, and getting work done in the meeting, not afterwards This handbook includes a guide to developing a flipped meeting culture in your organization, including: Pre-meeting communication and information sharing needs In-meeting group management and best practices Ideas for using video to make flipped meetings more efficient Flipping your meetings can help you win back time wasted in meetings, ensure that every meeting you attend is productive, and empower your teams to collaboratively make smarter, timelier decisions.

      Flipped meeting solves for the unengaging long lecture.

    1. One of the primary tasks of engineers is to minimize complexity. JSX changes such a fundamental part (syntax and semantics of the language) that the complexity bubbles up to everything it touches. Pretty much every pipeline tool I've had to work with has become far more complex than necessary because of JSX. It affects AST parsers, it affects linters, it affects code coverage, it affects build systems. That tons and tons of additional code that I now need to wade through and mentally parse and ignore whenever I need to debug or want to contribute to a library that adds JSX support.
    1. Since “virtual DOM” is more of a pattern than a specific technology, people sometimes say it to mean different things. In React world, the term “virtual DOM” is usually associated with React elements since they are the objects representing the user interface
    1. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough
    2. In the vast majority of cases there’s nothing wrong about wasted renders. They take so little resources that it is simply undetectable for a human eye. In fact, comparing each component’s props to its previous props shallowly (I’m not even talking about deeply) can be more resource extensive then simply re-rendering the entire subtree.
    1. This assumes that the module has been given a well-defined, stable description (the interface in the sense of information hiding).
    1. rehype is an ecosystem of plugins for processing HTML to do all kinds of things: format it, minify it, or wrap it programmatically into a document.
    1. However, although their approaches are different, one thing ASM have in common is their emphasis on network and code pedagogies: that is, trying to help users become coders and technicians, “sociologists of software,” to draw on Simondon (2010), who are far more able to shape ASM to meet their needs. Thus, developers of ASM do more than just make media systems; they teach others how to use them and modify them. As Matt Lee of GNU social argues,it is vitally important to me that anyone can set up a GNU social server on virtually any web hosting. I also want to make it as easy as possible to set up and install. To that end, I will personally help anyone who wants to get set up.
    1. Here's one quick way to test if your application has properly segregated itself between the Model, View, and Controller roles: is your app skinnable? My experience is that designers don't understand loops or any kind of state. They do understand templates with holes in them. Everybody understands mail merge. And if you say, "Apply the bold template to this hole," they kind of get that, too. So separating model and view addresses this very important practical problem of how to have designers work with coders. The other problem is there is no way to do multiple site skins properly if you don't have proper separation of concerns. If you are doing code generation or sites with different skins on them, there is no way to properly make a new skin by simply copying and pasting the old skin and changing it. If you have the view and the logic together, when you make a copy of the view you copy the logic as well. That breaks one of our primary rules as developers: have only one place to change anything.

      An effective way of testing whether your app practices separation of concerns within the MVC paradigm is whether or not it is "skinnable"

    1. In 1972 David L. Parnas published a classic paper entitled On the Criteria To Be Used in Decomposing Systems into Modules. It appeared in the December issue of the Communications of the ACM, Volume 15, Number 12. In this paper, Parnas compared two different strategies for decomposing and separating the logic in a simple algorithm. The paper is fascinating reading, and I strongly urge you to study it. His conclusion, in part, is as follows: “We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.”

      Parnas published a paper in 1972 about what heuristics are best to decide when to decompose a system into modules.

      His conclusion is that it is almost always wrong to start with a representation such as a flowchart (because things change).

      Instead he recommends focusing on a list of difficult design decisions, or decisions, once made, that will likely change. Then design each module is designed to hide such decisions from others.

    1. Domain-driven design separates the model layer “M” of MVC into an application, domain and infrastructure layer. The infrastructure layer is used to retrieve and store data. The domain layer is where the business knowledge or expertise is. The application layer is responsible for coordinating the infrastructure and domain layers to make a useful application. Typically, it would use the infrastructure to obtain the data, consult the domain to see what should be done, and then use the infrastructure again to achieve the results.

      Domain Driven Design separates the the Model in the MVC architecture into an application layer, an infrastructure layer and a domain layer.

      The business logic lives in the domain layer. The infrastructure layer is used to retrieve and store data. The application layer is responsible for coordinating between the domain and infrastructure layer.

  3. Sep 2020
    1. En concreto, el software libre implica que los usuarios tienen las cuatro libertades esenciales: (0) ejecutar el programa, (1) estudiar y modificar el código fuente del programa, (2) redistribuir copias exactas y (3) distribuir versiones modificadas.

      Estas son las cuatro libertades del sl

    1. I took the same approach with _layout.svelte and not just for the svelte-apollo client. Except I put all of that setup into another module (setup.js) and imported from _layout. I just couldn't stomach having all that code actually in my _layout file. It's for layout, supposedly, but it's the only component that is a parent to the whole app.
    2. I got this working by using _layout.svelte as the point to initialise and set the Client we can then use getClient in each route that uses this layout.
    1. If you need to call the function repeatedly, this is much, much faster than using eval.
    2. Developing software is usually easier if you break your project into smaller separate pieces, since that often removes unexpected interactions and dramatically reduces the complexity of the problems you'll need to solve
    1. I've committed to using Svelte, so I want to see it become highly adopted and not die or lose steam. For that, I believe we need to build up the ecosystem. Shared components, actions, transitions, etc. which make it easier for ourselves and others to build apps. I feel this will help Svelte continue to grow and will make it a better tool for our jobs. I see actions as one of the needed pieces to make this happen.
    2. I think hooks will be beneficial to the Svelte ecosystem, making sharing code for Svelte apps that solve common problems easier.
    1. Svelte started with no decoupling anywhere, with everything available at compile-time. Then <:Component> introduced separation at the component level -- but they're still coupled at properties. The spread feature would fill that gap. I see it as an intentional separation as opposed to an accidental shot at static analysis.
    2. I have no familiarity with Svelte internals, so much of your talk about what they would do eludes me. I'm just concerned with developer ergonomics
    1. Modern view libraries like React allow teams to build and maintain these components more easily than ever before, but it is still extraordinarily difficult to do so in a fully accessible way with interactions that work across many types of devices.
    1. Forwarding events from the native element through the wrapper element comes with a cost, so to avoid adding extra event handlers only a few are forwarded. For all elements except <br> and <hr>, on:focus, on:blur, on:keypress, and on:click are forwarded. For audio and video, on:pause and on:play are also forwarded.
    1. ¿Qué opinas?

      Es algo que siempre me cuesta trabajo, pero no sabía que es una cuestión donde hay posiciones y desacuerdos; la pensé como buena/mala práctica jaja. A mí me parece raro que la configuración se guarde en el mismo lenguaje de programación,si el usuario no es una persona que desarrolla software, que conozca el lenguaje o que le interese ver más allá de una interfaz de usuario. En esos casos un archivo de esos, hasta XML, me parece como una buena zona de intercambio, o como se llame, entre lo que el usuario configura y la manera en como esta se lleva acabo. Aunque luego también uno cae en tener demasiados archivos de configuración por todos lados jajaj. Pero ese es un caso entre muchos, lo que rescato es la idea de no poner pasos extra para el uso de un programa. Por ahí va la idea de tratar de tener una zona de intercambio entre distintas maneras de hacer una publicación y una interfaz de escritura que acerque al escritor promedio a las tecnologías de publicación automatizada y multiformato, muy comunes entre personas dedicadas al software.

    1. A small group of computer illiterate politicians, driven by fear and images of dying people have thrown the United Kingdom into chaos. They did this on the evidence of a thirteen year old computer programme written in the C language that has no comments, and that no one has seen or audited to ensure its basic assumptions are correct. This tragic event, which has cost the United Kingdom billions, is a perfect example of why critical software must be open source and open to peer review before it is accepted for any purpose where human life is at stake.
    1. Medical Software Development: Benefits and Implementation Strategy

      Read this guide by Cleveroad to learn more about medical software development.

    1. In general, my focus has shifted from optimization to DX. Partly because Svelte does a lot of the heavy lifting. For things that can be optimized on a need-to basis, I would rarely sacrifice DX.
    2. The language should work for developers, not the other way around.
    1. If component authors were in the habit of expecting a style prop, and applying it to top-level elements, we could do the same thing like so

      Seems to be the idea proposed here: https://github.com/sveltejs/svelte/pull/4749

    2. This has the merit of simplicity and obviousness, but it's not particularly ergonomic: it signals that we don't consider component themeability to be a problem worth solving properly.
    1. There is interactive state as well. What about modals that come up because something is clicked? What is the active tab? Is this menu open or closed? What scroll position are they at? There are infinite permutations of this. Imagine a warning bar that shows up seven seconds after the user logs in to warn user about their expired credit card which contains a custom styled select menu which can be in an open or closed state, but only on the user settings page.
    2. Remember the timing thing? We might think of timing as one generic form of state. There are countless other things that could be state related. Is the user logged in or not? What plan are they on? Is their credit card expired thus showing some kind of special message? Do situational things like time/date/geolocation change state? What about real-time data? Stuff from an API?
    1. Slide 13:

      “No man ever steps in the same river twice, for it's not the same river and he's not the same man.”

      ― Heraclitus

      Of course it’s not the same river — the river, is, what? The water flowing past your feet? The sound that it makes? These things are different at every moment. Our idea of ‘the river’ doesn’t correspond to anything in the real world. Understanding this concept means getting closer to an understanding of reality itself — once you fully absorb the impact of this idea, it changes you, from a person who didn’t have that understanding into one who does.

      And as you bask in your newfound zen-like enlightenment, you discover an almost spiritually calming effect — the world as it is right now is the only thing that matters, not the state of the world as it was yesterday or as it will be tomorrow.


      Slide 39:

      “No man ever steps in the same river twice, for it's not the same river and he's not the same man.”

      ― Heraclitus

      And I think Heraclitus probably understood it all along. There’s a paradox contained in this statement. If the concept of identity over time is meaningless, then what do we mean by ‘it’ and ‘he’?

    2. It turns out that even the length of time an element has been mounted is an important piece of state that determines what pixels the user sees. And some of this state can’t simply be lifted into our application state.

      What this means is that our desire to express UI using pure functions is in direct conflict with the very nature of the DOM. It’s a great way to describe a state => pixels transformation — perfect for game rendering or generative art — but when we’re building apps on the web, the idea chafes against the reality of a stateful medium.

    1. And because it's real CSS, rather than some camelCased quotes-everywhere impostor, we can take advantage of the 'tweak in devtools, paste back into our source code' workflow, which I personally couldn't live without.
    2. Your styles are scoped to the component. No more leakage, no more unpredictable cascade.
    3. It's fashionable to dislike CSS. There are lots of reasons why that's the case, but it boils down to this: CSS is unpredictable. If you've never had the experience of tweaking a style rule and accidentally breaking some layout that you thought was completely unrelated — usually when you're trying to ship — then you're either new at this or you're a much better programmer than the rest of us.
    4. It gets worse when you're working on a team. No-one dares touch styles authored by someone else, because it's often unclear what they're doing, what markup they apply to, and what disasters will unfold if you remove them. The consequence of all this is the append-only stylesheet. There's no way of knowing which code can safely be removed, so it's common to undo some existing style with another, more specific style — even on relatively small projects.
    1. It’s become increasingly common to divide code into components, rather than by file type. React, for example, allows for the collocation of a components markup and JavaScript. In Svelte, this is taken one logical step further: the Javascript, markup and styling for a component can all exist together in a single `.svelte`​ file
    1. These creeping changes help us forget how important our privacy is and miss that it’s being eroded.

      This is important we are normalizing the fact that our privacy is being taken slowly, update after update

    1. Secure-by-default is a great approach, but this is not that. It's not even, we know what's best. It's clean up your act or you're out. You really should provide an opt-in to running with scissors. Maybe like config.opt_in_to_dynamic_routes_you_dumbass = true. 1 Pick your reaction
    2. I too would like to know more about the security concerns that are the motivation to remove these useful dynamic routing components. The only thing I can think off is someone who accidentally exposes a private method public, is there more? The dynamic routes are a great way to keep the routing.rb DRY and avoid unneeded dependencies between the routing and the controller files, it has been quintessential Rails magic since version 1.0, surely there must be more serious security concerns to give up such important benefits? What are they? Do we really need to completely remove this from the code base, when removing it from the default routes.rb already would get you most of the security benefit?
    3. I'm sure the security overlords have our best interest in mind and I'd be happy to change my opinion if someone can explain this tradeoff better. I know I can recreate the functionality for myself but I also like to keep in mind what's best for Rails. Just a hand wavy "we've had this for almost 10 years, but it might become an issue in the future so let's preventively eliminate it" does not seem a good enough reason to cut a feature that can make code much more DRY and elegant.
    1. Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow. Some changes though are "substantial", and we ask that these be put through a bit of a design process and produce a consensus among the Yarn core team. The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project.
  4. Aug 2020
    1. For example, to search for text occurrences, I used ack-grep. Later on, I found that there is a faster approach using ag. Then, there is an even faster alternative called ripgrep.
    1. There’s just so much noise small businesses tend to ignore. But in Indonesia, that isn’t the case…yet. The software landscape there is similar to the 1990s in the US. It’s harder to piggyback off of existing software infrastructure — whether it’s payments or platforms — but there’s also a lot of obvious opportunity in software that no one is going after. The same could be said about investing elsewhere in Southeast Asia or in LatAm or Africa. There are fewer startups to compete with for attention, and it’s less of a marketing game than building a software company in the US.

      The software industry in southeast asia, latam or africa is similar to the US in the 1990s and is more about building than about marketing.

    2. As economist Carlotta Perez describes, we are now in the Deployment Phase of the internet in the US — meaning, we are in-process of exhausting all use cases for internet technologies in the US. What has traditionally happened at the end of a technology phase is oversaturation of investment dollars chasing smaller returns. Valuations go up, returns go down, and investors lose their money. (Sound familiar?) On a company level, what this means is, if not careful, a lot of companies will end up wasting marketing dollars in this type of landscape. Companies in the 2020s, unlike in the 1990s, need to really be performance-marketing driven in order to compete. The end of last year certainly showed us many examples of well-funded companies that could not make the unit economics work. The software industry has become a marketing game.

      According to Carlotta Perez we are in the Deployment Phase of internet as a technology. Meaning we are exhausting the use cases for the internet and more money is chasing decreasing returns.

      As a result companies need to be more efficient with their marketing spend in the 2020s compared to before.

      The software industry has become a marketing game

    1. The RAT model sees software development as an off-line program-construction activity composed of these parts: defining, decomposing, estimating, implementing, assembling, and finishing

      This is what can lead to the 'there is only version 1.0' problem - and improvements / iterations fall to the sidelines.

      This can have a number of consequences

      • over designed / engineered
      • doing unnecessary work
      • lack of user feedback and ability to accommodate it
      • rigid / fragile architecture
    1. Digital work has significantly faster feedback loops for productivity. Software, quite simply, can produce and iterate new things at a daily if not hourly or minute basis.

      Software is uniquely suited for iterative development. This also creates faster feedback loops for productivity.

    1. Stallman has also stated that considering the practical advantages of free software is like considering the practical advantages of not being handcuffed, in that it is not necessary for an individual to consider practical reasons in order to realize that being handcuffed is undesirable in itself.
    2. Free software thus differs from: proprietary software, such as Microsoft Office, Google Docs, Sheets, and Slides or iWork from Apple. Users cannot study, change, and share their source code. freeware, which is a category of proprietary software that does not require payment for basic use.
    1. GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.
    2. How does the licensing work in this new setup? Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.
    1. Speed example -- over 829 files, the "find -exec" method took 26 seconds while the "find -print0 | xargs --null" method tool 0.7 seconds. Significant difference.