github.com

A nice cheatsheet/summary for software architecture

Space, the final frontier yuu • 1y ago • 95%

Researchers detected for the first time in space the carbon molecule methyl cation (CH3+) in the protoplanetary disk of the young star system d203-506: ~1,350 light-years away in the Orion Nebula

skyheadlines.com

> For the first time ever in space, scientists discovered a novel carbon molecule known as methyl cation (CH3+). This molecule is significant because it promotes the synthesis of more complex carbon-based compounds. 

Emacs yuu • 1y ago • 100%

Help collecting statistics to optimize Emacs GC defaults

Originally posted on https://emacs.ch/@yantar92/110571114222626270 > Please help collecting statistics to optimize Emacs GC defaults > > Many of us know that Emacs defaults for garbage collection are rather ancient and often cause singificant slowdowns. However, it is hard to know which alternative defaults will be better. > >Emacs devs need help from users to obtain real-world data about Emacs garbage collection. See the discussion in https://yhetil.org/emacs-devel/87v8j6t3i9.fsf@localhost/ > >Please install https://elpa.gnu.org/packages/emacs-gc-stats.html and send the generated statistics via email to emacs-gc-stats@gnu.org after several weeks.

> In May 2023 over 90,000 developers responded to our annual survey about how they learn and level up, which tools they're using, and which ones they want. > ... > This year, we went deep into AI/ML to capture how developers are thinking about it and using it in their workflows. Stack Overflow is investing heavily in enhancing the developer experience across our products, using AI and other technology, to get people to solutions faster.

NOTE: This is primarily an invitation for the "[SEI and White House OSTP to Explore the Future of Software and AI Engineering](https://www.eventbrite.com/e/us-leadership-in-software-engineering-ai-engineering-workshop-registration-601593190427)", but there is this big section on the "future of software engineering" that is very interesting.  > As discussed in [Architecting the Future of Software Engineering: A Research and Development Roadmap](https://insights.sei.cmu.edu/blog/architecting-the-future-of-software-engineering-a-research-and-development-roadmap), the SEI developed six research focus areas in close collaboration with our advisory board and other leaders in the software engineering research community > ... > AI-Augmented Software Development: By shifting the attention of humans to the conceptual tasks that computers are not good at and eliminating human error from tasks where computers can help, AI will play an essential role in a new, multi-modal human-computer partnership... taking advantage of the data generated throughout the lifecycle > > Assuring Continuously Evolving Software Systems: ...generating error-free code, especially for trivial implementation tasks... generating surprising recommendations that may themselves create additional assurance concerns... develop a theory and practice of rapid and assured software evolution that enables efficient and bounded re-assurance of continuously evolving systems > > Software Construction through Compositional Correctness: ...unrealistic for any one person or group to understand the entire system... need to integrate (and continually re-integrate) software-reliant systems.. create methods and tools that enable the intelligent specification and enforcement of composition rules that allow (1) the creation of required behaviors (both functionality and quality attributes) and (2) the assurance of these behaviors at scale > > Engineering AI-enabled Software Systems: ...AI-enabled systems share many parallels with developing and sustaining conventional software-reliant systems. Many future systems will likely either contain AI-related components, including but not limited to LLMs, or will interface with other systems that execute capabilities using AI... focus on exploring which existing software engineering practices can reliably support the development of AI systems and the ability to assess their output, as well as identifying and augmenting software engineering techniques for specifying, architecting, designing, analyzing, deploying, and sustaining AI-enabled software systems > > Engineering Socio-Technical Systems: ... As generative AI makes rapid progress, these societal-scale software systems are also prone to abuse and misuse by AI-enabled bad actors via techniques such as chatbots imitating humans, deep fakes, and vhishing... leverage insights from such as the social sciences, as well as regulators and legal professionals to build and evolve societal-scale software systems that consider these challenges and attributes. > > Engineering Quantum Computing Software Systems: ...enable the programming of current quantum computers more easily and reliably and then enable increasing abstraction as larger, fully fault-tolerant quantum computing systems become available... create approaches that integrate different types of computational devices into predictable systems and a unified software development lifecycle.

> Conclusion: Four Areas for Improving Collaboration on ML-Enabled System Development > >Data scientists and software engineers are not the first to realize that interdisciplinary collaboration is challenging, but facilitating such collaboration has not been the focus of organizations developing ML-enabled systems. Our observations indicate that challenges to collaboration on such systems fall along three collaboration points: requirements and project planning, training data, and product-model integration. This post has highlighted our specific findings in these areas, but we see four broad areas for improving collaboration in the development of ML-enabled systems: >Communication: To combat problems arising from miscommunication, we advocate ML literacy for software engineers and managers, and likewise software engineering literacy for data scientists. > > Documentation: Practices for documenting model requirements, data expectations, and assured model qualities have yet to take root. Interface documentation already in use may provide a good starting point, but any approach must use a language understood by everyone involved in the development effort. > > Engineering: Project managers should ensure sufficient engineering capabilities for both ML and non-ML components and foster product and operations thinking. > > Process: The experimental, trial-and error process of ML model development does not naturally align with the traditional, more structured software process lifecycle. We advocate for further research on integrated process lifecycles for ML-enabled systems. More: https://conf.researchr.org/details/icse-2022/icse-2022-papers/153/Collaboration-Challenges-in-Building-ML-Enabled-Systems-Communication-Documentation PS: This one is from months ago, but still interesting

medium.com

> At Pinterest, Closeup recommendations (aka Related Pins) is typically a feed of recommended content (primarily Pins) that we serve on any pin closeup. Closeup recommendations generate the largest amount of impressions among all recommendation surfaces at Pinterest and are uniquely critical for our users’ inspiration-to-realization journey. It’s important that we surface qualitative, relevant, and context-and-user-aware recommendations for people on Pinterest. See also: https://group.lt/post/46301

github.com

> The repository consists of three layers: > > 1. Finding Category layer lists the overarching categories > 2. General Finding layer lists high-level findings > 3. Specific Finding layer lists low-level findings Just an overview of the general findings  More: https://cmu-sei-podcasts.libsyn.com/a-penetration-testing-findings-repository

medium.com

> 1. Introduction: What are Miho and its role as a brand; what problem are they solving; how they are solving the problem > 1. Competitive analysis > 1. Logo and Design Guidelines > 1. Information Architecture > 1. Iterations ... in the form of wireframes > 1. UI Designs: Homepage: appealing, informative, and engaging... users could easily know “what” and “for whom” this website is for; Product detail page; Gift Shop Page; Gift detail page; About Page;

medium.com

> 1. [Affectiva's Emotion AI](https://www.affectiva.com/product/affectiva-media-analytics-for-qualitative-research) ... facial analysis and emotion recognition to understand user emotional responses > 2. [Ceros' Gemma](https://www.ceros.com/gemma/) ... generate new ideas, optimize existing designs, ... learn from your ideas and creative inputs, providing designers with personalized suggestions > 3. [A/B Tasty](https://www.abtasty.com/) ... UX designers to run A/B tests and optimize user experiences > 4. [Slickplan](https://slickplan.com/sitemap/visual-generator) ... sitemap generator and information architecture tool > 5. [SketchAR](https://sketchar.io/) ... creating accurate sketches and illustrations > 6. [Xtensio](https://xtensio.com/design/) ... user personas, journey maps, and other UX design deliverables > 7. [Voiceflow](https://www.voiceflow.com/) ... create voice-based applications and conversational experiences PS: Sounds like an ad, but still interesting to see tools in the wild that support AI for these conceptual phases in software engineering

uxdesign.cc

> In today’s hybrid work landscape, meetings have become abundant, but unfortunately, many of them still suffer from inefficiency and ineffectiveness. Specifically, meetings aimed at generating ideas to address various challenges related to people, processes, or products encounter recurring issues. The lack of a clear goal in these meetings hinders active participation, and the organizer often dominates the conversation, resulting in a limited number of ideas that fail to fully solve the problem. Both the organizer and attendees are left feeling dissatisfied with the outcomes. > > ... > > The below sample agenda assumes that problem definition is clear. If that is not the case, hold a session prior to the ideation session to align on the problem. Tools such as interviewing, [Affinity Mapping](https://careerfoundry.com/en/blog/ux-design/affinity-map/), and developing [User Need statements](https://www.nngroup.com/articles/user-need-statements/) and ["How Might We"](https://www.nngroup.com/articles/how-might-we-questions/) questions can be useful in facilitating that discussion. > A sample agenda for ideation sessions > > Estimated time needed: 45–60 minutes > > 1. Introduction & ground rules (2 minutes) > - Share the agenda for the ideation session. > - Review any [ground rules or guidelines](https://www.ideou.com/blogs/inspiration/7-simple-rules-of-brainstorming) for the meeting. > - Allow time for attendees to ask questions or seek clarification. > > 2. Warm-up exercise (5–10 minutes) > - Conduct a warm-up exercise to foster creativity and build rapport among participants such as [30 Circles](https://www.ideo.com/blog/build-your-creative-confidence-thirty-circles-exercise) or [One Thing, Nine Ways](https://mbcollab.com/blog/six-creative-warmups-to-get-your-team-in-the-right-mindset). > - Choose an activity that aligns with the goals of the meeting and reflects the activities planned for the session. A quick Google search for “warm-up exercises design thinking” will return several potential activities. > > 3. Frame the problem (2 minutes) > - Share a single artifact (slide, Word Doc, section of text in whiteboard tool) that serves as a summary of the problem, providing participants with a reference point to anchor their thinking and revisit as needed throughout the session. > > 4. Guided ideation & dot voting (30 minutes) > - Select 1–2 guided ideation exercises such as [Crazy 8s](https://www.iamnotmypixels.com/how-to-use-crazy-8s-to-generate-design-ideas/), [Mash-up](https://www.mural.co/blog/remote-ideation-techniques), [Six Thinking Hats](https://www.debonogroup.com/services/core-programs/six-thinking-hats/). A quick Google search for “ideation techniques design thinking” will return tons of potential exercises. > - Provide clear instructions. > - Use [Dot Voting](https://lucidspark.com/blog/dot-voting) and/or [Prioritization Matrix](https://www.ibm.com/design/thinking/page/toolkit/activity/prioritization) to select the most promising ideas. > > 5. Next steps & closing remarks (5 minutes) > - Assign owners or champions for the selected ideas who will be responsible for driving their implementation (if not already known). > - Summarize the key decisions made and actions to be taken. > - Clarify any follow-up tasks or assignments. > - Express gratitude for participants’ contributions and conclude the meeting on a positive note.

Space, the final frontier yuu • 1y ago • 100%

Webb proves galaxies' stars transformed the early universe from opaque to transparent: they allowed light to travel freely by heating and ionizing intergalactic gas, clearing vast regions around them

> 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

Space, the final frontier yuu • 1y ago • 100%

Astrophysicists confirm the faintest galaxy ever seen in the early universe

newsroom.ucla.edu

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

www.zdnet.com

cross-posted from: https://group.lt/post/65921 > Saving for the comparison with the next year

Rust Programming yuu • 2y ago • 100%

Nightly builds of all official rust mdbooks in the EPUB format, The Rust eBookshelf

> 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.

building.nubank.com.br

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.

Sysadmins for sysadmins yuu • 2y ago • 100%

Foundational DevOps Patterns

cross-posted from [!softwareengineering@group.lt](https://group.lt/c/softwareengineering): 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.

arxiv.org

cross-posted from [!softwareengineering@group.lt](https://group.lt/c/softwareengineering): 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.