چند وقتی است که به همراه یکی از دوستان، درس Machine Learning with Graphs دانشگاه استنفورد را هم‌خوانی و دنبال می‌کنیم. چند نکته به نظرم رسید که مناسب دیدم اینجا یادداشت کنم.

• همان طور که در خود درس گفته شده است “گراف‌ها مرزهای جدید یادگیری عمیق (ِِDeep Learning) هستند“
• چرا گراف؟ گراف‌، زبانی عمومی برای توصیف و تحلیل موجودیت‌ها و روابط / تعاملات بین آنهاست.
• آموختن یادگیری ماشین گرافی برای من به مراتب دشوارتر از یادگیری ماشین رایج و غیرگرافی است.
• کاربردهای یادگیری ماشین با گراف “شگفت‌انگیز” و تا حدی “ترسناک” است. باور کنید!

در اینجا فهرستی از نمونه کاربردهای یادگیری ماشین با گراف را می‌توانید ببینید.

• Node classification: Predict a property of a node /Example: Categorize online users-items
• Link prediction: Predict whether there are missing links between two nodes / Example: Knowledge graph completion
• Graph classification: Categorize different graphs / Example: Molecule property prediction–
• Clustering: Detect if nodes form a community / Example: Social circle detection
• Other tasks:
  — Graph generation: Drug discovery
  — Graph evolution: Physical simulation

اجازه دهید یک کار روزمره را به یک مساله گراف تبدیل کنیم:
فرض کنید که کاربران یک پیام‌رسان مانند تلگرام، واتس اپ یا اینستاگرام را به مانند گره گراف و پیام‌ باز-ارسالی (فوروارد شده) از یک کاربر به کاربر دیگر را هم به مانند یال گراف و تعداد پیام باز-ارسالی رد و بدل شده را مانند وزن یال در نظر بگیریم. اگر مدلی به کمک یادگیری ماشین با گراف طراحی کنیم، به نظر شما این مدل به چه سوالاتی می‌تواند پاسخ دهد!

و اما آخرین نکته‌ی جالب‌: آموختم که “گوگل اولین شرکتی بود که اینترنت را یک گراف دید“!

Reading more:
CS224W: Machine Learning with Graphs, Stanford / Winter 2021 (Slides, Video)
CS224W: Machine Learning with Graphs, Stanford / Fall 2019 (Slides, Video)

گزیده:
شاید ریاضی به ما یاد ندهد که چگونه عشق را “جمع کنیم” یا نفرت را “کم کنیم”، اما به ما امید می‌دهد که هر مساله‌ای راه حلی دارد.
ناشناس (مرجع)

… relative estimating like with Planning Poker suffers from a bootstrapping problem: How does a team select the initial estimates to which they’ll compare?

My recommendation is that when a team first starts playing Planning Poker, team members identify two values that will establish their baseline. They do this without playing Planning Poker. They do it just through discussion. After the baseline is established, team members can use Planning Poker to estimate additional items.

Ideally, the team is able to identify both a two-point story and a five-point story. There is evidence that humans estimate most reliably when sticking within one order of magnitude.

Identifying a two-point product backlog item and a five-point item does a good job of spanning this order of magnitude. Many other items can then be more reliably compared against the two and the five.

If finding a two and a five proves difficult, look instead for a two and an eight, or a three and an eight. Anything that spans the one to 10 range where we’re good estimators will work.

Avoid Starting with a One-Point Story
I like to avoid starting with a one-point story. It doesn’t leave room for anything smaller without resorting to fractions, and those are harder to work with later.

Additionally, comparing all subsequent stories to a one-point story is difficult. Saying one product backlog item will take two or three times longer than another seems intuitively easier and more accurate than saying something will take 10 times longer.

I made this point in my 2005 “Agile Estimating and Planning” book (now also a video course). In 2013, it was confirmed by Magne Jørgensen of the Simula Research Lab. Jørgensen, a highly respected researcher, conducted experiments involving 62 developers. He found that “using a small user story as the reference tends to make the stories to be estimated too small due to an assimilation effect.”

Why Use Two Values for a Baseline?
Establishing a baseline of two values allows for even the first stories being estimated to be compared to two other items. This is known as triangulating and helps achieve more consistent estimates.

If a team has established a baseline with two- and five-point stories, team members can validate a three-point estimate by thinking whether it will take longer than the two and less time than the five.

Citing again the research of Jørgensen, there is evidence that the direction of comparison matters. Comparing the item being estimated to one story that will take less time to develop and another that will take longer is likely to improve the estimate.

Reference: Mike Cohn, mountaingoatsoftware.com

Quote:
“The higher the price of information in a software team, the less effective the team is.”
― Yegor Bugayenko, Code Ahead: Volume 1

from: www.extremeprogramming.org

The author of this website is Don Wells. He learned about how teams become unproductive while at Honeywell and General Electric. He then learned a great deal about teams becoming super productive while building expert diagnostic systems for the US Army and Ford Motor Co. Many artificial intelligence practices are now common in software development.

The turning point in current software development came in the mid-1990s. Many people were re-examining the idea that software must be built like hardware. Jeff Sutherland and Ken Schwaber were formalizing a new process called SCRUM. Alistair Cockburn was working on Crystal Clear. Chrysler was doing its part by trying to build traditional business systems using object-oriented technology. This is a common approach now that Java is used in almost all domains, but was very advanced in the previous millennia.

Don was hired on to the Chrysler Comprehensive Compensation (C3) project as an expert in object technology and GUIs. It didn’t take long for him to spot some serious trouble. The team was splintered into 3 groups that worked in competition instead of cooperation. The project was becoming overdue. Estimates were showing it way over budget. It was also way too complex and riddled with redundant code (Conway’s Law) to ever work reliably in production. His assessment of the situation was to start over. There was time to make the deadline but only if the team worked together in cooperation and sharing as opposed to competition and isolation.

You can probably imagine that starting a project over after millions of dollars were already invested is a tricky situation. Don had to wait for exactly the right moment. That moment came when a consultant named Kent Beck was hired to optimize the C3 system’s performance. Kent decided to spend a half hour with each of the developers to get an idea of what needed to be done. When he began talking to Don he ended up spending 3 hours. At the end of that time Don had convinced Kent that the current code base would never make it into production. Kent presented that result to Chrysler management and they agreed.

The project was halted and Don began not just mending fences but completely tearing them down between team members. Chrysler management noticed what he was doing and offered him the position of chief architect. Don graciously refused while explaining his concept of everyone owning and contributing to the system’s design. No one understood his goal yet.

Kent Beck was hired to spend a couple days each month on the C3 project. Chrysler also hired Ron Jeffries to join notable agile proponents Martin Fowler and Chet Hendrickson on the project. Kent mixed together the best practices Don Wells is on the left from several emerging agile processes with things he had learned while working with Ward Cunningham. The C3 team created a new process formulation by watching what helped or hindered. Doing more of what helps and less of what hinders resulted in a minimal process with high flexibility.

Kent wanted the team to integrate code often, but it wasn’t working. Kent had appointed an integration czar with integration lieutenants in a hierarchy. Integrating that way put a chief architect back into the project and slowed them down till they were integrating once every three weeks and taking days to do it. A hot spot of complexity was also brewing. Don came up with an idea. It would solve the current integration problem, allow design simplifications, and lead the team to his ultimate goal of collective ownership.

Don proposed to the team that they set up an extra computer on an empty desk where all integration would take place. They would integrate and release new code to the repository when ever they wanted without prior permission so long as it ran all the unit tests. Management hated the idea. The team was mixed about it. Management played their trump card by not allowing Don to have an extra computer. So Don simply moved his own computer to the empty desk and told everyone it was the integration station. He wanted to do more pair programming anyway.
That simple change made a huge difference. People began releasing code at least once a day if not more. Sharing an integration computer made people more cooperative and the design tighter because everyone was responsible for making it better. Anyone could change any code and know changes would not be lost. People began writing more unit tests then they had before because it ensured their code would run even if some one else made some changes.
The real prize in that change was what came to be known as collective ownership. The entire team owns the entire code base. The entire team is responsible for developing and extending the system design. The team worked together cooperatively at a much faster pace than anyone expected. Don has some rough estimates and believes the team was going six and a half times faster than before the project was restarted.
With C3 back on schedule Don moved back to Ford Motor Co. This time he was to help a financial application get back on track. The application was the Vehicle Cost and Profitability System (VCAPS) that calculated how much it actually cost to build a car or truck. It was in trouble because of serious quality and performance issues. More time was spent fixing bugs than adding required features.
The first big change Don made was to write a unit test framework and create the first unit tests. It was a “white knuckle” assignment because he had two weeks to write code and one week to debug. The unit tests and framework took the entire first two weeks to finish. But once the unit tests were in place the actual code only took one week to write, no debugging needed. The assignment was brought in on time with none of the expected bugs. This was a good start.
As the number of unit tests grew management noticed a one third reduction in production bugs. At that time Don was able to set up an integration station and began continuous integration and collective ownership. More Extreme Programming (XP) practices were introduced until the second XP project was running. As production bugs dropped even further the team became more productive eventually reaching a factor of ten times. This second XP project verified that XP was a viable process and C3 was not just an anomaly.
Soon after leaving the VCAPS project in 1999 Don created this website. At that time information on the XP process was either very Extreme Programming Perspectives XP Agile Universe 2002 XP Agile Universe 2003 confusing or biased towards Smalltalk projects. There was also a great deal of discussion going on about whether or not XP would even work. Don perceived a need for a simple explanation of the basics that everyone would agree upon. Having been on two XP transformations he felt qualified to be the author.

Never regret a day in your life. Good days give happiness, bad days give experiences, worst days give lessons, and best days give memories
—Richard Feynman

پیش‌گفتار:
هر وقت گذرم به گراف و اصل لانه کبوتری می‌افتد یاد استاد عزیزم آقای دکتر بهروز قلی‌زاده در دانشگاه شریف می‌افتم. یادش به‌خیر همیشه جاده قزوین-زنجان-تبریز یک پای ثابت مثال‌های گراف و مسیریابی ایشان بود. با وجود علاقه‌ام به گراف، در تمام این سال‌ها گذرم به گراف و مساله‌های آن نخورده بود، تا این که زمستان پارسال برای آمادگیِ آزمون ابتدایی دوره دکترا معروف به Field Of Study، مطالب مربوط به گراف و درخت و مسیرها را دوباره مرور کردم.

پایگاه داده گرافی:
برای انجام پروژه‌ای نیاز شد که با پایگاه داده گرافی (Graph Database) آشنا شوم. به کمک یکی از دوستان باتجربه‌ام (حسین آقا)، کار با Neo4J را شروع کردم و به کمک راهنما و زیرساخت آموزشی Neo4J و البته همراهی حسین جان، توانستم با آن کار کنم. به راستی که چه دنیای متفاوت و جذابی است. آن چه با مشقت فراوان در پایگاه داده رابطه‌ای می‌توان انجام داد، اینجا با یک کد ساده می‌توان به دست آورد. اگر دوست داشتید نگاهی به آن بیندازید می‌توانید از این آدرس (Neo4j Graph Database Sandbox) استفاده کنید. چه زیباست!

گزیده:
«پرارزشترین بخش [مطالعه ریاضی] لحظه‌ای است که می‌گویی آها!. ذوق کشف و لذت فهمیدن چیزی جدید. احساس ایستادن بالای یک بلندی و رسیدن به دیدی شفاف و واضح.» مریم میرزاخانی در مصاحبه با گاردین (مرجع)

مرجع عکس: اینجا

What is Essence?

Essence provides us with a thinking framework that allows teams to understand where they are and acts as a foundation for their way-of-working. At the heart of the Essence approach is the Essence Kernel – a simple state-driven model of software engineering. The Essence Kernel captures the small set of things that are universal to all software engineering endeavors; the things that a team always has to consider or work with when developing software.

The kernel contains seven key elements – Requirements, Software System, Team, Work, Way of Working, Opportunity and Stakeholders.

Reference: www.semat.org

Quote:
“When I asked Sam Shillace, who ran Gmail and Google Apps for four years, about the costliest mistake he’s seen engineers make, his response was, “Trying to rewrite stuff from scratch — that’s the cardinal sin.” ― Edmond Lau, The Effective Engineer

فایل ارائه در اسلایدشیر: www.slideshare.net

گزیده:

“Agility is principally about mindset, not practices.” ― Jim Highsmith