Announcing the European region for Amazon Q Developer

Post Syndicated from Brian Beach original https://aws.amazon.com/blogs/devops/amazon-q-developer-european-region/

As I sat down to write this post, my daughter called from the top of the Eiffel Tower on a trip with her high school class. While she excitedly pointed her camera toward the Parisian skyline, I was struck by how technology has transformed our concept of distance. Her world, at eighteen, is infinitely more connected than the one I knew at her age. I couldn’t help but smile at the timing of this call, because today Amazon Q Developer is expanding to Europe.

The launch of Amazon Q Developer Pro Tier in the Frankfurt (eu-central-1) region marks a significant milestone for our European customers, addressing two critical needs: data residency and performance optimization. For organizations that need to meet EU data residency requirements, the ability to store customer content within EU boundaries can help provide the assurances they require. Beyond compliance, this regional presence brings performance benefits. European customers will experience reduced latency in their interactions with Amazon Q Developer, as requests are processed closer to home. This proximity not only improves response times but also enhances the overall development experience, making real-time interactions with Amazon Q Developer more fluid and natural.

Amazon Q Developer Pro tier users now have the choice of creating a profile in N. Virginia (us-east-1) or Frankfurt (eu-central-1). Associated data – including customizations – is stored in this region. While data is stored in Frankfurt, Amazon Q utilizes cross-region inferencing to optimize request processing. At launch, this includes Frankfurt, Ireland, Paris and Stockholm, as shown in the following image.

A map of Western Europe showing connections between four cities: Frankfurt (shown as a central hub with concentric circles) connected by curved orange lines to Stockholm (Sweden), Ireland, and Paris (France). The map has a dark background with countries shown in gray.

Finally, it is important to note that certain operations, such as querying AWS resources in other regions (e.g. “List my S3 buckets in Tokyo”), will naturally involve cross-region calls regardless of your Q Developer profile’s location.

The Frankfurt region includes all GA features except the command line and the ability to chat with Support. You can read more in the Amazon Q Developer User Guide. We invite you to experience these new capabilities by upgrading to the Pro tier and selecting Frankfurt as your region during profile creation. Get started with Amazon Q Developer, and share your feedback with us as we continue to expand our global presence.

Седмицата (7–12 април)

Post Syndicated from Светла Енчева original https://www.toest.bg/siedmitsata-7-12-april/

Седмицата (7–12 април)

Докато разсъждавам върху въпроса, който Боряна Телбис задава в предишния бюлетин – дали сме живи, или не, – 16-годишно момче падна от петия етаж на столична професионална гимназия. Лекарите се борят за живота му. Засега основната хипотеза е, че тийнейджърът е скочил сам. Новината мина някак между другото. Лесно е да сочим с пръст виновници за деца жертви и да искаме по-строги наказания. Лесно е да се опитваме да „поправяме“ учениците със сила – като ги накараме да зубрят православни догми и им слагаме оценки за дисциплина. Или по соломоновски да „разрязваме“ децата на две – с необмислени закони за т.нар. споделено родителство. По-трудно е да разберем какво се случва в умовете и душите им.

Това е въпросът, който поставя британският минисериал Adolescence („Юношество“). Четирите му епизода станаха повод за сериозни разговори и в Европа, и в САЩ – за това как възрастните не разбират поколението Z, за токсичната мъжественост, за емпатията… В България обаче тези разговори така и не стигат до ушите на вземащите решения за бъдещето на децата. Така че, ако искате да поставите интереса на учениците в центъра на образованието, имате по-голям шанс за успех в някое шведско училище, отколкото тук.

И все пак в България има хора с ясна идея каква би трябвало да бъде образователната система. Донка Дойчева-Попова разговаря с три специалистки по преподаването на чужди езици, които са в час със съвременните методи в областта си – Мария Караиванова, Смиляна Ангелова и Ирина Мартинова.

Като стана дума за образование, се замислих и за американските университети от т.нар. Бръшлянова лига. Ореолът им рязко започна да потъмнява, когато администрацията на Тръмп взе да им реже държавното финансиране – било заради студентски протести в подкрепа на Палестина, било защото подкрепят разнообразието и социалното включване. Това е и темата на статията на Яна Хашъмова „Политика, просвета и провал. Кой се страхува от американските университети?“. В нея авторката развива тезата, че президентът Тръмп е емоционално незрял и се държи като тийнейджър.

Притеснявам се, че ако споделя чуденията си в коя ли фаза от психосексуалното развитие по Фройд се намира Доналд Тръмп, този бюлетин може да стане неприличен. В същото време самият американски президент се хвали колко държави му „целуват задника“ (не, няма да цензурирам думите на един държавен глава със звездички) заради митата, с които ги заплашва. Представете си как някой комплексар взема заложници и непрекъснато променя условията за освобождаването им, за да му звънят по телефона, а той да се кефи колко е важен и как всички му се молят. Е, в случая целият свят е взет за заложник.

От драмата с митата (тя вече заприлича на сапунена опера) се замислих дали протекционизмът е патриотичен. Всяка година преди Великден новинарските емисии изобилстват от репортажи за „лошите“ вносни яйца и агнешко. Но по-добре ли ще живеем, ако в България нищо не се внася, а се произвеждат и потребяват само български продукти? Представете си живот без кафе и шоколад, но с български смартфони, компютри и операционни системи. Ако изобщо е възможно да се направят тук.

Ала всякакви популистки идеи могат да намерят почва, когато хората не вярват в институциите. За плаващите пясъци на институционалното недоверие е и статията на Валентин Вълканов. Колкото повече ни се обяснява, че така стоят нещата, толкова по-силно се убеждаваме, че те изобщо не са наред, казва авторът. Поводът за този безрадостен извод е решението на Конституционния съд след проверката на изборната документация в 2204 секции. От нея българските граждани разбраха, че не трябва да вярват на очите си и изобщо – че всичко е относително.

Изобщо – държавата ни е престъпник, смята Емилия Милчева. Когато бащата на поредното дете, загинало на пътя – Сияна, казва, че българската държава е опасна за гражданите си, това е истина. Най-лесно е да се хвърли цялата вина върху един шофьор. Но проблемът с некачествените ремонти на пътищата е огромен, а политици и институции си прехвърлят топката. Колко от милиардите, отпуснати за пътища в последните 15 години, действително са вложени в пътища, а не в чували, пита Емилия.

И все пак в България има хора, които са решили да се борят и да не се предават, колкото и да е трудно. Ина Иванова ни среща с една от тях – Диана Димова от „Мисия Криле“, за която пролетта започва от една птичка. Тя е посветила живота си на най-уязвимите – жени и деца в риск, бежанци. Заедно с колегите си се опитва да усилва гласа на онези, които нямат такъв, или пък той е много тих. Колкото и трудно и рисковано да е това.

Едни защитават членове на уязвими групи, други – едри бизнес интереси. Анахит Хачикян обяснява мръсна дума ли е лобизмът и кога играта загрубява. Всяка организация, която работи за дадена кауза и цели да повлияе в процеса на вземане на политически решения, е вид лобистка организация и в това само по себе си няма нищо лошо, казва Анахит. Лобирането обаче трябва да се извършва по определени правила. Когато политици биват подкупвани със скъпи подаръци и луксозни пътувания, за да вземат някакво решение, вече имаме проблем.

Но да си отпуснем душата с десетия епизод на Т.Е. от Е.Т. Любимата ни Елена Телбис няма да ни излъже, че всичко е наред, но поне ще се посмеем.

Не знам за смях ли е, или за сълзи, но Националният исторически музей има проблем със съвременното изкуство. Поне в степента, в която то е провокативно. Затова инсталацията „Гранични цветя“ на Иван Мудов е премахната от двора на НИМ още преди официалното ѝ откриване, без дори художникът да бъде уведомен за това. От музея очаквали хубавки найлонови цветя, а дворът им се оказал осеян с „отпадъци“. Тази история ми припомни как преди десетина години парчето от Берлинската стена пред НДК беше „почистено“ от графитите си и измазано със сива боя.

По традиция завършвам с препоръка.

Ако познавате млади хора, които не помнят социализма, но са убедени, че тогава хората са живели по-добре, пуснете им латвийския сериал „Съветски дънки“. Препоръчвам го и на всички, които искат да разберат тоталитарния режим отпреди 1989 г., както и на онези, които имат нужда да си го припомнят. Липсата на свобода каква музика да слушаш и какви дрехи да носиш, ченгетата, които те следят навсякъде, корупцията и неравенството, които уж ги нямаше, насилието над личността…

Сериалът, съсценаристка на който е българката Теодора Маркова, е нещо като среща на „1984“ и „Полет над кукувиче гнездо“. И докато зрителят се чуди дали всъщност гледа комедия, или драма, го халосва по главата финал, който не се вписва в стереотипите за хепиенд, и все пак е оптимистичен.

Винаги препоръчвам да ни ударите едно рамо, ако искате да ни четете и гледате. Защото благодарение на подкрепата ви съществуваме.

Подкрепете ни

[$] Managing multiple sources of page-hotness data

Post Syndicated from corbet original https://lwn.net/Articles/1016722/

Knowing how frequently accessed a page of memory is (its “hotness”) is a
key input to many memory-management heuristics. Jonathan Cameron, in a
memory-management track at the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit, pointed out that the number of sources
of that kind of data is growing over time. He wanted to explore the
questions of what commonality exists between data from those sources, and
whether it makes sense to aggregate them all somehow.

Introducing sub-issues: Enhancing issue management on GitHub

Post Syndicated from Shaun Wong original https://github.blog/engineering/architecture-optimization/introducing-sub-issues-enhancing-issue-management-on-github/


Recently we launched sub-issues, a feature designed to tackle complex issue management scenarios. This blog post delves into the journey of building sub-issues, what we learned along the way, how we implemented sub-issues, and the benefits of being able to use sub-issues to build itself.

What are sub-issues?

Sub-issues are a way to break a larger issue into smaller, more manageable tasks. With this feature, you can now create hierarchical lists within a single issue, making it easier to track progress and dependencies. By providing a clear structure, sub-issues help teams stay organized and focused on their goals.

For example, I often realize that a batch of work requires multiple steps, like implementing code in different repositories. Breaking this task into discrete sub-issues makes it easier to track progress and more clearly define the work I need to do. In practice we’ve noticed this helps keep linked PRs more concise and easier to review.

A screenshot showing a list of sub-issues on GitHub.

A brief history

Issues have long been at the heart of project management on GitHub. From tracking bugs to planning feature development, issues provide a flexible and collaborative way for teams to organize their work. Over time, we’ve enriched this foundation with tools like labels, milestones, and task lists, all to make project management even more intuitive and powerful.

One of the key challenges we set out to solve was how to better represent and manage hierarchical tasks within issues. As projects grow in complexity, breaking down work into smaller, actionable steps becomes essential. We want to empower users to seamlessly manage these nested relationships while maintaining the simplicity and clarity GitHub is known for.

Our journey toward sub-issues began with a fundamental goal: to create a system that integrates deeply into the GitHub Issues experience, enabling users to visually and functionally organize their work without adding unnecessary complexity. Achieving this required careful design and technical innovation.

Building sub-issues

To build sub-issues, we began by designing a new hierarchical structure for tasks rather than modifying the existing task list functionality. We introduced the ability to nest tasks within tasks, creating a hierarchical structure. This required updates to our data models and rendering logic to support nested sub-issues.

From a data modeling perspective, the sub-issues table stores the relationships between parent and child issues. For example, if Issue X is a parent of Issue Y, the sub-issues table would store this link, ensuring the hierarchical relationship is maintained.

In addition, we roll up sub-issue completion information into a sub-issue list table. This allows us to performantly get progress without having to traverse through a list of sub-issues. For instance, when Issue Y is completed, the system automatically updates the progress of Issue X, eliminating the need to manually check the status of all sub-issues.

We wanted a straightforward representation of sub-issues as relationships in MySQL. This approach provided several benefits, including easier support for sub-issues in environments like GitHub Enterprise Server and GitHub Enterprise Cloud with data residency.

We exposed sub-issues through GraphQL endpoints, which let us build upon the new Issues experience and leverage newly crafted list-view components. This approach provided some benefits, including more efficient data fetching and enhanced flexibility in how issue data is queried and displayed. Overall, we could move faster because we reused existing components and leveraged new components that would be used in multiple features. This was all made possible by building sub-issues in the React ecosystem.

We also focused on providing intuitive controls for creating, editing, and managing sub-issues. To this end, we worked closely with accessibility designers and GitHub’s shared components team that built the list view that powers sub-issues.

Our goal was to make it as easy as possible for users to break down their tasks without disrupting their workflow.

Using sub-issues in practice

Dogfooding is a best practice at GitHub and it’s how we build GitHub! We used sub-issues extensively within our own teams throughout the company to manage complex projects and track progress. Having a discrete area to manage our issue hierarchy resulted in a simpler, more performant experience. Through this hands-on experience, we identified areas for improvement and ensured that the feature met our high standards.

Our teams found that sub-Issues significantly improved their ability to manage large projects. By breaking down tasks into smaller, actionable items, they maintained better visibility and control over their work. The hierarchical structure also made it easier to identify dependencies and ensure nothing fell through the cracks.

Gathering early feedback

Building sub-issues was a team effort. Feedback from our beta testers was instrumental in shaping the final product and ensuring it met the needs of our community. For example, understanding how much metadata to display in the sub-issue list was crucial. We initially started with only issue titles, but eventually added the issue number and repository name, if the issue was from another repository.

Building features at GitHub makes it really easy to improve our own features as we go. It was really cool to start breaking down the sub-issues work using sub-issues. This allowed us to experience the feature firsthand and identify any pain points or areas for improvement. For example, the has:sub-issues-progress and has:parent-issue filters evolved from early discussions around filtering syntax. This hands-on approach ensured that we delivered a polished and user-friendly product.

These lessons have been invaluable in not only improving sub-issues, but also in shaping our approach to future feature development. By involving users early and actively using our own features, we can continue to build products that truly meet the needs of our community. These practices will be important to our development process going forward, ensuring that we deliver high-quality, user-centric solutions.

Call to action

Sub-issues are designed to help you break down complex tasks into manageable pieces, providing clarity and structure to your workflows. Whether you’re tracking dependencies, managing progress, or organizing cross-repository work, sub-issues offer a powerful way to stay on top of your projects.

We’d love for you to try sub-issues and see how they can improve your workflow. Your feedback is invaluable in helping us refine and enhance this feature. Join the conversation in our community discussion to share your thoughts, experiences, and suggestions.

Thank you for being an integral part of the GitHub community. Together, we’re shaping the future of collaborative development!

The post Introducing sub-issues: Enhancing issue management on GitHub appeared first on The GitHub Blog.

The collective thoughts of the interwebz