yuu

Early galaxies' stars allowed light to travel freely by heating and ionizing intergalactic gas, clearing vast regions around them.

Cave divers equipped with brilliant headlamps often explore cavities in rock less than a mile beneath our feet. It’s easy to be wholly unaware of these cave systems – even if you sit in a meadow above them – because the rock between you and the spelunkers prevents light from their headlamps from disturbing the idyllic afternoon.

Apply this vision to the conditions in the early universe, but switch from a focus on rock to gas. Only a few hundred million years after the big bang, the cosmos was brimming with opaque hydrogen gas that trapped light at some wavelengths from stars and galaxies. Over the first billion years, the gas became fully transparent – allowing the light to travel freely. Researchers have long sought definitive evidence to explain this flip.

New data from the James Webb Space Telescope recently pinpointed the answer using a set of galaxies that existed when the universe was only 900 million years old. Stars in these galaxies emitted enough light to ionize and heat the gas around them, forming huge, transparent “bubbles.” Eventually, those bubbles met and merged, leading to today’s clear and expansive views.

More: https://eiger-jwst.github.io/index.html

The nature of an ultra-faint galaxy in the cosmic Dark Ages seen with JWST https://arxiv.org/abs/2210.15639

cross-posted from: https://group.lt/post/65921

Saving for the comparison with the next year

I suppose it only makes sense to raise awareness on the benefits of the freely licensed software and services from the fediverse over the dangerous and unethical proprietary services in existence such as Reddit now going to IPO. That happened to Twitter->Mastodon, can happen to Reddit->Lemmy as well.

I suppose as well that the users most likely to be open to the idea would be the free software, culture users to try it. Besides, an effort on content creation and content creators to make it an attractive place.

What are your thoughts? What were the efforts so far? What are the challenges? Is it so hard to make people migrate?

This project aims at providing nightly builds of all official rust mdbooks in epub format. It is born out of the difficulty I encountered when starting my rust apprenticeship to find recent ebook versions of the official documentation.

If you encounter any issue, have any suggestion or would like to improve this site and/or its content, please go to https://github.com/dieterplex/rust-ebookshelf/ and file an issue or create a pull request.

Always interesting to read real world applications of the concepts. Nubank's framework is a mix of storytelling, design thinking, empathy mapping, ...

storytelling can be used to develop better products around the idea of understanding and executing the “why’s” and “how’s” of the products. Using the techniques related to it, such as research, we can simplify the way we pass messages to the user.

Nubank's framework has three phases:

1. Understanding: properly understand the customer problem. After that, we can create our first storyboard. When working on testing with users, a framework is good to guarantee that we’re considering all of our ideas.
2. Defining: how we’re going to communicate the narrative. As you can see, the storyboard is very strategic when it comes to helping influence the sequence of events and craft the narrative. Here the "movie script" is done. Now make de "movie's scene".
3. Designing: translate the story you wrote, because, before you started doing anything, you already knew what you were going to do. Just follow what you have planned... Understanding the pain points correctly, we also start to understand our users actions and how they think. When we master this, we can help the customer take the actions in the way that we want them to, to help them to achieve their goals.
4. Call to action: By knowing people’s goals and paint points, whether emotional or logistical, we can anticipate their needs.... guarantee that it is aligned with the promises we made to the customer, especially when it comes to marketing. Ask yourself if what you’re saying in the marketing campaigns are really what will be shown in the product.

cross-posted from [email protected]: https://group.lt/post/46385

Adopting DevOps practices is nowadays a recurring task in the industry. DevOps is a set of practices intended to reduce the friction between the software development (Dev) and the IT operations (Ops), resulting in higher quality software and a shorter development lifecycle. Even though many resources are talking about DevOps practices, they are often inconsistent with each other on the best DevOps practices. Furthermore, they lack the needed detail and structure for beginners to the DevOps field to quickly understand them.

In order to tackle this issue, this paper proposes four foundational DevOps patterns: Version Control Everything, Continuous Integration, Deployment Automation, and Monitoring. The patterns are both detailed enough and structured to be easily reused by practitioners and flexible enough to accommodate different needs and quirks that might arise from their actual usage context. Furthermore, the patterns are tuned to the DevOps principle of Continuous Improvement by containing metrics so that practitioners can improve their pattern implementations.

The article does not describes but actually identified and included 2 other patterns in addition to the four above (so actually 6):

• Cloud Infrastructure, which includes cloud computing, scaling, infrastructure as a code, ...
• Pipeline, "important for implementing Deployment Automation and Continuous Integration, and segregating it from the others allows us to make the solutions of these patterns easier to use, namely in contexts where a pipeline does not need to be present."

The paper is interesting for the following structure in describing the patterns:

• Name: An evocative name for the pattern.
• Context: Contains the context for the pattern providing a background for the problem.
• Problem: A question representing the problem that the pattern intends to solve.
• Forces: A list of forces that the solution must balance out.
• Solution: A detailed description of the solution for our pattern’s problem.
• Consequences: The implications, advantages and trade-offs caused by using the pattern.
• Related Patterns: Patterns which are connected somehow to the one being described.
• Metrics: A set of metrics to measure the effectiveness of the pattern’s solution implementation.

cross-posted from [email protected]: https://group.lt/post/46385

Adopting DevOps practices is nowadays a recurring task in the industry. DevOps is a set of practices intended to reduce the friction between the software development (Dev) and the IT operations (Ops), resulting in higher quality software and a shorter development lifecycle. Even though many resources are talking about DevOps practices, they are often inconsistent with each other on the best DevOps practices. Furthermore, they lack the needed detail and structure for beginners to the DevOps field to quickly understand them.

In order to tackle this issue, this paper proposes four foundational DevOps patterns: Version Control Everything, Continuous Integration, Deployment Automation, and Monitoring. The patterns are both detailed enough and structured to be easily reused by practitioners and flexible enough to accommodate different needs and quirks that might arise from their actual usage context. Furthermore, the patterns are tuned to the DevOps principle of Continuous Improvement by containing metrics so that practitioners can improve their pattern implementations.

The article does not describes but actually identified and included 2 other patterns in addition to the four above (so actually 6):

• Cloud Infrastructure, which includes cloud computing, scaling, infrastructure as a code, ...
• Pipeline, "important for implementing Deployment Automation and Continuous Integration, and segregating it from the others allows us to make the solutions of these patterns easier to use, namely in contexts where a pipeline does not need to be present."

The paper is interesting for the following structure in describing the patterns:

• Name: An evocative name for the pattern.
• Context: Contains the context for the pattern providing a background for the problem.
• Problem: A question representing the problem that the pattern intends to solve.
• Forces: A list of forces that the solution must balance out.
• Solution: A detailed description of the solution for our pattern’s problem.
• Consequences: The implications, advantages and trade-offs caused by using the pattern.
• Related Patterns: Patterns which are connected somehow to the one being described.
• Metrics: A set of metrics to measure the effectiveness of the pattern’s solution implementation.

Adopting DevOps practices is nowadays a recurring task in the industry. DevOps is a set of practices intended to reduce the friction between the software development (Dev) and the IT operations (Ops), resulting in higher quality software and a shorter development lifecycle. Even though many resources are talking about DevOps practices, they are often inconsistent with each other on the best DevOps practices. Furthermore, they lack the needed detail and structure for beginners to the DevOps field to quickly understand them.

In order to tackle this issue, this paper proposes four foundational DevOps patterns: Version Control Everything, Continuous Integration, Deployment Automation, and Monitoring. The patterns are both detailed enough and structured to be easily reused by practitioners and flexible enough to accommodate different needs and quirks that might arise from their actual usage context. Furthermore, the patterns are tuned to the DevOps principle of Continuous Improvement by containing metrics so that practitioners can improve their pattern implementations.

The article does not describes but actually identified and included 2 other patterns in addition to the four above (so actually 6):

• Cloud Infrastructure, which includes cloud computing, scaling, infrastructure as a code, ...
• Pipeline, "important for implementing Deployment Automation and Continuous Integration, and segregating it from the others allows us to make the solutions of these patterns easier to use, namely in contexts where a pipeline does not need to be present."

The paper is interesting for the following structure in describing the patterns:

• Name: An evocative name for the pattern.
• Context: Contains the context for the pattern providing a background for the problem.
• Problem: A question representing the problem that the pattern intends to solve.
• Forces: A list of forces that the solution must balance out.
• Solution: A detailed description of the solution for our pattern’s problem.
• Consequences: The implications, advantages and trade-offs caused by using the pattern.
• Related Patterns: Patterns which are connected somehow to the one being described.
• Metrics: A set of metrics to measure the effectiveness of the pattern’s solution implementation.

Attention economy is a pretty important concept in today's socioeconomic systems. Here an article by Nielsen Norman Group explaining it a bit in the context of digital products.

Digital products are competing for users’ limited attention. The modern economy increasingly revolves around the human attention span and how products capture that attention.

Attention is one of the most valuable resources of the digital age. For most of human history, access to information was limited. Centuries ago many people could not read and education was a luxury. Today we have access to information on a massive scale. Facts, literature, and art are available (often for free) to anyone with an internet connection.

We are presented with a wealth of information, but we have the same amount of mental processing power as we have always had. The number of minutes has also stayed exactly the same in every day. Today attention, not information, is the limiting factor.

There are many scientific works on the topic; here some queries in computer science / software engineering databases:

• IEEE Xplore
• ACM DL
• arXiv

Another related article by NN/g: The Vortex: Why Users Feel Trapped in Their Devices

it is a week since I have been using Perject as an alternative/replacement to packages like tabspaces and persp. Perject is much better than those, and I have yet to experience a bug. The workflow is:

1. create a collection of projects: perject-open-collection
2. create a project under a collection: perject-switch
3. add buffer to project: perject-add-buffer-to-project

Then can create collections, projects, ... and switch between them from any frame. It does auto save state, and I found it very good in reloading the saved collections/projects; I have not experienced any bug with it while I would experience much bugs with persp...

Also Perject integrates with GNU Emacs built-ins for all that, such as desktop, project.el, tab-bar, ...

The author, overideal, released it recently, but it already is one my favorite Emacs packages. Really worth it trying it out.

My config if anyone wants to try it out https://codeberg.org/yymacs/yymacs/src/branch/main/yyuu/mod/yyuu-mod-emacs-uix-space.el#L43-L111

• Google: AppSheet
• Apple: SwiftUI
• Microsoft: PowerApps
• Amazon: HoneyCode, Amplify Studio