רברסים 2016

ב 19-20 בספטמבר, יתקיים כנס רברסים 2016.

למי שלא מכיר, כנס זה הוא ככל הנראה הכנס המשמעותי ביותר בתחום התוכנה בישראל. כמו כן:

  • הוא קרוב יותר לסטאראט-אפים וחברות בינוניות – מאשר לחברות גדולות.
  • אין בו תוכן ממומן – כל הכבוד!
  • הקהילה בוחרת את התוכן (או לפחות משפיעה במידה רבה) – מה שאומר שיהיו קצת באזזים.
  • הקווים המנחים של התוכן הוא לא להציג Tutorials למתחילים – שאפשר למצוא באינטרנט, לא להציג מוצרים (אלא אם אלו פרוייקטי Open Source שאתם עובדים עליהם), ולנסות להציג לקחים מהמציאות – שפעמים רבות קשה למצוא אותם בחיפוש בגוגל.
מקור השם \"רברסים\" הוא קיצור של \"רברס עם פלטפורמה\" – שמו של הפודקאסט של אורי ורן (מחברת אאוטבריין, רן כבר בחברה משלו), שיזמו ככל הנראה את הכנס הזה, ועדיין תומכים בו. רברס עם פלטפורמה (על מלגזה) הוא דבר מורכב לביצוע (בשפה הקיבוצית) – והכוונה של הפודקאסט הייתה לעסוק בתוכן משמעותי ומורכב.
תמונה מרברסים 2015, בטכניון
הכנס השנה מתקיים במכון וייצמן. השתתפות איננה עולה כסף, אך ישנו רישום ומספר המקומות מוגבל.
אם אתם פנויים בימים הללו, ומחפשים כנס תוכנה טוב – אני מציע לכם להירשם ולהגיע.

אם אתם מתכוונים להגיע, הגשתי שתי הצעות להרצאות:

Microservices Insights with Microservices

שבא אנסה לתת תובנות על יישום ארכיטקטורה מבוססת מיקרו-שירותים.
לבור את המוץ מהתבן – ולנסות להתמקד במה שבאמת חשוב במיקרו-שירותים.
לתת קווים מנחים, ארוכי טווח, שיכולים לסייע לאבחן אם היישום שלנו הוא בכיוון הנכון או לא.

 הבסיס הוא המצגת שלי מ DevConTLV, אך אחדש וארענן אותה.

Software Punk: examining controversial ideas in Software Development – that just might work

בה אנסה לבחון כמה רעיונות מטופשים (שנויים במחלוקת) בהנסת תוכנה, למשל: להפסיק להשתמש בגיט, או לכתוב פחות Unit Tests – ולהראות שעל אף שהם רחוקים מהקונצנזוס, עדיין יש בהם הגיון ושאולי כדאי לקחת מהם משהו (אולי אפילו: לאמץ בהתלהבות).

אם אתם מתכוונים להגיע, אנא הצביעו על כך באתר (זמין רק לאחר רישום) ע\"י לחיצה על הכפתור:

כמובן שזו הזדמנות נהדרת להצביע גם להצעות אחרות – ולהשפיע מה אתם רוצים לראות בכנס.

אם אתם בכנס – קפצו גם לומר שלום.

נתראה,
ליאור

מצגת על מיקרו-שירותים ב DevConTLV בפורים

בפורים, ממש לפני כמה שבועות הופעתי בכנס DevConTLV שהיה בסינמטק.

מכיוון שרבים וטובים הציגו את נושא המיקרו-שירותים, בחרתי לא להשתמש במצגת \"המוכנה\" שלי על מבוא למיקרו-שירותים (שדומה לפוסט בנושא בבלוג) – ולנסות לחדש קצת (וגם לקחת נימה יותר קלילה שמתאימה לפורים).

האמת שהייתי במהלך וירוס שהכה בי, ומי שהיה בהרצאה ראה כנראה שהייתי חלש וכמה פעמים אף התקשתי לסיים משפטים 🙁

בכל זאת, אני חושב שהחומר מעניין לכל מי שמתעניין במיקרו-שרותים, ולכן העלתי את המצגת לסליידשר (עקבו אחר הלינק).

ברור לי שמצגות לא בנויות לקריאה ולכן הוספתי למצגת הערות (פתקיות צהובות) שישלימו את החסר – ויהפכו את המצגת למהנה לקריאה.

מקווה שתמצאו את החומר מעניין ושימושי!

ליאור

הכנס השני לארכיטקטורת תוכנה (30 לנובמבר – 1 בדצמבר)

בסוף החודש הקרוב, 30 בנובמבר – 1 בדצמבר, יתקיים בהרצליה הכנס השני לארכיטקטורת תוכנה.

הכנס מאורגן ע\"י IASA ואילתם.

IASA, למי שלא מכיר, הוא ארגון עולמי שמנסה ליצור קהילה גלובלית עולמית של ארכיטקטים – בכדי לקדם את המקצוע הזה, ואת המקצועיות שלו ברחבי העולם. ל IASA יש סניף ישראלי – והחבר\'ה שם מנסים לארגן הרצאות מעניינות ודיונים בין אנשי מקצוע (כלומר: ארכיטקטים) על דילמות של המקצוע (ארכיטקט מהו? כיצד טרנד האג\'ייל משפיע על תפקיד הארכיטקט, וכאלה).

ILTAM, היא קהילה מקצועית, רחבה יותר, המורכבת בעיקר מחברות הייטק גדולות ומבוססות (לא רק חברות תוכנה נטו: אלתא, 3M, וצה\"ל למשל – הם חברים) במטרה לקדם ולשתף ידע.

בשונה משנה שעברה בה הייתה נוכחות גדולה של האקדמיה וחברות מהגדולות במשק – עיקר המשקל השנה ניתן לחברות סטארט-אפ ונושאים שרלוונטיים (גם) עבורן.

היום ראשון מורכב מהרצאות. הנה התכנית:

ביום שני מתקיים Tutorial בהדרכתה של Rebecca Wirfs-Brock (שהגיעה לארץ במיוחד, אני מניח), בנושאי ארכיטקטורה באג\'ייל ו Quality Attributes בפרט (הנה פוסט שפירסמתי בנושא, אם אתם רוצים לקבל מושג במה מדובר).

האם כדאי לבוא?

תקשיבו, זו שאלה דיי אינדיבדואלית, ואני בד\"כ זהיר במתן המלצות. בכל זאת, כשאני מסתכל התכנים – נראה לי שהצליחו לרכז באמת שורה של נושאים ומרצים מעניינים ביום הראשון – שרלוונטיים לאנשי-תוכנה כמעט מכל הסוגים.
היום השני הוא באמת ממוקד יותר לארכיטקטים, או מי שרוצה שהתעמק בטכניקה תאורטית שהתמורה שלה להשקעה היא ארוכת-טווח. אני לא יודע להמליץ ספיצית על ה Tutorial שנבחר, אבל אם הוא נבחר באותה רוח של בניית האג\'נדה ליום הראשון – ייתכן בהחלט וזה יהיה Tutorial מוצלח!
  • אני נותן הרצאה על מיקרו שירותים (עדיין לא החלטתי בדיוק איך להעביר את הנושא…). אם אתם מגיעים – קפצו לומר שלום!
  • קצת אחרי ייתן הרצאה יונתן ממן, שכתב כאן פוסט אורח בנושא – ממש לאחרונה.
  • הנה אתר הכנס: http://conference70.wix.com/sw-architecture
  • בטופס ההרשמה שבאתר, ניתן לקבל הנחה אם מזינים את המילה \"Presenter\", בסעיף של קבוצת שיוך (אופס, אני מקווה שבאמת היה מותר לי לספר את זה…).
שיהיה בהצלחה!
ליאור
 

רשמים מכנס רברסים 2015 [פוסט אורח]

בשבוע שעבר השתתפתי בועידת רברסים 2015, וחשבתי לנצל את במת הבלוג של ליאור כדי לשתף ברשמים, מכיון שהוא לא היה יכול להגיע השנה.

קודם כל, אין ספק שהכנס היה מצוין, הן מבחינת התכנים והן מבחינת הארגון. בחירת המיקום (הפקולטה למדעי המחשב בטכניון) איתגרה את עכברי המרכז \"לחדש את הדרכונים\" כפי שהזכיר רן תבורי. מצד שני הפיצוי היה בדמות ארוחת צהריים חלבית שהיתה בהחלט יותר מוצלחת מהפלאפל (הלא רע) באדיבות גוגל מהועידה הקודמת.

אז מה זה רברסים? למי שלא מכיר –  פודקאסט ישראלי (http://www.reversim.com/) בנושאי תוכנה שמשדרים אורי להב ורן תבורי מאז 2008. הפודקאסט הזה הוא אחד הגורמים שהשפיעו המון על הסטרטאפים הישראלים שקמו בשנים האחרונות, משום שהוא נתן את הטון לשיתוף ידע ואוירה קהילתית.

כאשר התבססה קהילת מאזינים, פנו רן ואורי לארגן כנס לקהילה – כל התכנים מובאים על ידי אנשים מקהילת ההייטק הצעירה, עם הימנעות מתוכן פירסומי, וללא התערבות של חברות גדולות המספקות מימון.

הגעתי בבוקר ברכבת מהמרכז, האוירה נעימה וגיקית. מצאתי שאנשים מדברים בקבוצות קטנות. הרבה הגיעו בקבוצות ממקום העבודה, והיו הסנוניות הבודדות, שהגיעו לבד. קצת היה קשה להתחבר.



קצת על הנוכחות הנשית בכנס

היה לנו מספר עגום ביותר של נשים נוכחות (לדעתי לא יותר מ 20, כשמספר הרשומים בכל יום עבר את ה 300).

ליטל חסין היתה ממארגנות הכנס, ורוח חיה באופן כללי וייצגה את פורום הנשים TechNit.

את הביתן של Rails Girls ארגנו אילונה ונטלי – זהו הסניף הישראלי של Rails Girls שמארגן אירועי קידוד והאקתונים לנשים ולבנות.

אני ארגנתי ארוחת צהריים לנשים בחבורה – פשוט לקחנו את צלחות האוכל ומצאנו פינה לשבת ולשוחח. לא היתה אג\'נדה מסוימת (מעבר לסבב היכרות שבו כל אחת הציגה את עצמה), אבל זה היה מאד מחזק בתור מיעוט, לשבת לרגע עם עוד (א)נשים כמוני, ולשתף בחוויות\\תסכולים\\ידע.

עם מישהי אחת יצא לי לשבת גם לשיחת המשך, היא שיתפה אותי בדילמות ממקום העבודה, ואני שיתפתי אותה בכמה תובנות מ(מרום?) שנות נסיוני.

אגב, את הרעיון קיבלתי מכנס על Mobile שהייתי בו בחו\"ל לפני כמה שנים. קיבלתי אז מייל כמה ימים לפני הכנס שהזמין אותי ל women\'s networking lunch. גם שם היינו כ-20 נשים, וישבנו בשני שולחנות, פשוט לאכול יחד ולשוחח.

ולסיום אשתף אתכם בחוויות של משתתפת בכנס טכני בחו\"ל שזכתה למשפטים נוסח \"את לא תביני…\".

לדעתי מצבנו בארץ פחות גרוע…. (=~ יותר טוב).

קצת על הנושאים בכנס

את האג\'נדה המלאה של הכנס אפשר למצוא כאן. אספר בקצרה על ההרצאות שמהן נהניתי ולמדתי הכי הרבה.
ההרצאות ההמעניינות ביותר בעיני היו Architecture Overview על המערכת הקיימת של חברה מסוימת, עם כמה דגשים:
  • איך התפתחה הארכיטקטורה עם הזמן כדי לענות לבעיות (בעיקר scalability אבל לא רק) 
  • עקרונות ותבניות של הארכיטקטורה (והמנצח השנה, טמ-טמ-טמ: Micro-Services !!!) 
  • רכיבי open source מרכזיים בפתרון. עבורי, זזו היתה אחת ההזדמנויות לעשות קורס מזורז בטכנולוגיות החמות והמוכחות ביותר, ברמה של – \"שם\", \"מספר אישי\", ו\"תפקידך בכוח\".
מוטיב נוסף שחזר בכמה הרצאות היה – שפות מבוססות JVM
Closure, שפה פונקציונלית המזכירה את Scheme/LISP, הוזכרה כשפה שנבחרה למימוש אחת המערכות. הרצאה אחת הוקדשה לסקאלה (Scala) ואחת לגרובי (Groovy), כולל טיפים לאיך להכניס את השפות הללו לפרויקט java קיים. לקחתי מההרצאות האלה כמה רעיונות פרקטיים לפרויקט שלנו.
הרצאות ה ignite היו מדליקות – זה רצף של הרצאות קצרות של 5 דקות כל אחת, בעירוב נפלא של נושאים טכניים ו soft skills. למדתי דברים חדשים מההרצאה על HTTP 2.0
לצערי לא נשארתי להרצאות של סוף היום – ביום הראשון הייתה בעצם סטנד אפ, ובשני – אירוע ה hall of shame שבו אנשים מתחרים על הסיפור הבאג המזעזע\\מביך\\יקר ביותר שיצא תחת ידיהם.
כל השקפים מצטברים לאט בלינק הבא: https://hackpad.com/RS15-Presentations-htx5kKsSeCv
הקלטות של ההרצאות יפורסמות בעתיד.
אני מצרפת כאן את הסיכומים שלי מהסשנים שנכחתי בהם (הנקודות – באנגלית).

Scaling with micro services – Wix architecture:
  • Clusters divided to end user view (public) / editing / media serving
  • Micro services architecture…but other services can read directly from other services DB
  • No DB transactions at all (only applicative transactions / eventual consistency)
  • Save logic in the editor: Save each page in a separate REST call, where page ID is a hash on the content. Then save the site object , with a list of all pages (new IDs) to complete the “transaction”
  • Media is stored in several places: CDN + Google cloud + amazon, and fallback logic to all locations. If everything fails – media is loaded from Wix servers.
  • JS code renders a json configuration object – avoid server side HTML rendering for maximum scale. 4 servers serve all of Wix traffic.
  • SEO content requires server side HTML rendering and for that they are a separate cluster of 12 servers.

Some limitations\\challenges in the microservices architecture
  • Debugging is not easy
  • They implemented no dependency management between the services
  • API versioning, as APIs (within their version) do not change. Need forward + backward compatibility









Reactive by Example

Slides are here

The reactive manifesto describes a common pattern for distributed systems:

A reactive system is:

  • Responsive – requires quick responses. predicted response time + QoS (Quality of Service).
  • Resilient – remains responsive even in case of a system failure. Failure is to be expected. Almost a \"1st class citizen\" in the system\'s design.
  • Elastic – can grow up/down in scale, according to traffic\'s requirements.
  • Message-Driven – asynchronous, loosely coupled, messages

A “metrics collecting system” was described as an example of a reactive pattern system.
Open source components mentioned, that were used:

MicroServices and Event-Driven architecture with Clojure and Kafka

The business is to analyze marketing campaigns on mobile applications.
This was another example of a system architecture rapidly scaling rapidly (during 1.5 years) from:
10+services, 250M events\\day, 5 servers+3DBs
into:
100+ services, to 2.5B events a day, 200 servers+20DBs

Architecture highlights:

  • All raw data is stored in S3
  • Services communicate with events, IO is non-blocking
  • Event stream is using Kafka (high scale messaging system)
  • key attribute is that the event can be consumed by multiple consumers and is not erased from the queue.
  • A “conveyor belt” analogy
  • Not fast enough for real-time response (OK for this use case)

Other elements in their architecture:

  • Clojure as programming language (see below). Motivation: JVM-based, enforces functional paradigm.
  • Consul for service discovery
  • Docker for service deployment
  • Statsd for JVM metrics
  • Testing is done directly on production systems (no test systems!!!)

JVM-based languages

In 3 different lectures they addressed the next generation of JVM-based languages, after Java.

The common of all of them:

  • All Running on JVM and compile to bytecode, 
  • Leveraging one of the best runtime engines that exist today
  • Compatible with other development done in Java

Clojure

  • Enforce functional paradigm.
  • Suitable for sequence-based processing, very suitable for event processing.

Scala

  • Everything is an expression (not a statement)
  • Remove a lot of coding overhead (“boilerplate code”)
  • Strong collection framework
  • Functions are first-class objects (Like JS)
  • Option – a cool way to eliminate the need to handle null in your code (Option is an array of size 1 or 0, enforcing you to always take into consideration the fact that the value may not exist there)\\
  • Traits – partially implemented interfaces, a good way to model effective multiple inheritance
  • Lazy evaluation built into the language, thus preventing the need to code if (debugLevel>INFO)
  • Domain specific languages. E.g. a powerful tests
  • Java 8 took many great ideas from Scala but still there’s an inherent gap 

Groovy

  • Java code is also groovy code so you can have a gradual adoption
  • You can have a java interface and groovy implementation (Need to implement Groovy Loader)
  • JSonSlurper – parse json objects, and then access them in an JS-like way (addressing the names of the properties)
  • RESTClient/HttpBuilder for easier work with HTTP/REST
  • Now to become part of Apache foundations

Recommendations how to add a new JVM-based language to an existing project

  • In the tests
  • For new projects
  • In a specific layer
  • For an isolated component

Other information fragments \\ Interesting technologies

Storm in under a second
Storm in a framework for event streaming and processing, implemented in Java.
Its deployment can be done on a single machine
The lecture was about how to achieve a controlled response time with an events framework, which theoretically does not guarantee response time

HTTP 2.0
How it overcomes many limitations in how browsers work today
Good source is: http://daniel.haxx.se/http2/http2-v1.11.pdf

Gamification of code reviews
An open source plugin for git hub providing a count of how many people commented on code differences, including leaderboard
https://github.com/tzachz/github-comment-counter
Advantage – publish the people who do the most code reviews. Gamification!!!

סיכום

ליאור: תודה רבה לרחלי אבנר על הפוסט! כן ירבו.

כנס הארכיטקטורה הראשון של IASA ו ILTAM

עדכון (11 בדצמבר, 2014)

מסתבר שהקליטו את ההרצאה שלי (20 דקות) – ואפשר למצוא אותה כאן ביוטיוב, ואת המצגת ב Slideshare.
תודה רבה לחיים שהיה בין מארגני הכנס, ארגן את ההקלטה, וכתב על ההרצאה בבלוג שלו (ניתן למצוא בבלוג גם הרצאות אחרות מהכנס).

——

שבוע שעבר, בימים שני ושלישי התקיים \"כנס הארכיטקטים הראשון\" של IASA ואילתם.

IASA, למי שלא מכיר, הוא ארגון עולמי שמנסה ליצור קהילה גלובלית עולמית של ארכיטקטים – בכדי לקדם את המקצוע הזה, ואת המקצועיות שלו ברחבי העולם. ל IASA יש סניף ישראלי – והחבר\'ה שם מנסים לארגן הרצאות מעניינות ודיונים בין אנשי מקצוע (כלומר: ארכיטקטים) על דילמות של המקצוע (ארכיטקט מהו? כיצד טרנד האג\'ייל משפיע על תפקיד הארכיטקט, וכאלה).

ל IASA יש גם קבוצה ב LinkedIn  (דורשת הצטרפות) – בה חברים רבים מהארכיטקטים שאני מכיר. אם אתם ארכיטקטים – אני ממליץ לשקול להצטרף (אני חושב שלא יאשרו לכם להצטרף אם לא כתוב בקורות החיים שלכם שאתם ממש ארכיטקטים באופן רשמי).

את ILTAM, אני אודה – אני לא ממש מכיר לעומק. זו גם קהילה מקצועית, רחבה יותר, המורכבת בעיקר מחברות הייטק גדולות ומבוססות (לא רק חברות תוכנה נטו: אלתא, 3M, וצה\"ל למשל – הם חברים) במטרה לקדם ולשתף ידע.

זו סצינה שונה למדי מסצינת ה\"סטארט-אפים\" הישראלית: אנשים שונים, תחומי התמקדות שונים, וקצת סגנון שונה.
שמחתי לראות השנה את יואב אברהמי מ Wix מופיע – שהוא חבר דיי ברור בסצינת הסטארט-אפים.

אני חושב שלשתי הקהילות יש מה ללמוד אחת מהשנייה. באופן אולי מפתיע, אני חושב שדווקא ל\"תעשיה המסורתית\" (מסורתית = חברות שחיות 15 שנה או יותר) יש יותר מה ללמוד מסצינת הסטארט-אפים למרות שרבים בתעשיה, לעניות דעתי – עדיין לא מבינים את זה.

אני העברתי הרצאה על \"חמשת תחומי המומחיות של הארכיטקט\" – שבעיקר הייתה מבוססת על הפוסט שפירסמתי באותו השם – כאשר מעט פיתחתי כמה מהרעיונות.

בחלק השני השתתפתי בפאנל מקצועי (עם ד\"ר עירית הדר מאונ\' חיפה, עצמון הד-טוב VP R&D בפונטיס, וניר סלע – מנהל פיתוח התוכנה ברפאל) שדן במיומנויות הנדרשות בכדי להיות ארכיטקט, או אולי – ארכיטקט \"מוצלח\". פעם ראשונה שאני משתתף בכזה פאנל – ואני מקווה שהצלחתי לתרום לדיון ולעניין.

מקור

אני אספר בקצרה על שני sessions שהיו לי מעניינים במיוחד:

מחקר על תפקיד הארכיטקט, כיצד הוא נתפס ע\"י אלו שעושים אותו וכו\'
נעשה ע\"י סופיה שרמן, נעמי Unkelos-Shpigel (אני לא רוצה לכתוב את זה לא נכון :)), וד\"ר עירית הדר (שהייתה איתי גם בפאנל).

אם אתם זוכרים את הקריאה (Lean Startup/Enterprise) לאמת תחושות בטן בצורה אמפירית, הסשן הציג כמה אימותים שאולי מסתדרים עם כמה תחושות בטן של רבים – אך הם עדיין בגדר היפותזה כל עוד לא אומתו בצורה רצינית.

רוב התוצאות שאציג להלהן הן מסקר בו נשאלו מאה ומשהו ארכיטקטים על העבודה שלהם: מה הם עושים מול מה שהם חושבים שהם צריכים לעשות. כל התוצאות הן בסקאלה של 1 עד 5 (כלומר: 3.5 ממוצע) – כאשר המספר המדויק לא ברשותי – אני מספק רק \"קריאה\" שלי מגרף מסוג Bar Chart. למשל:

  • ארכיטקטים הם חלק מצוות הפיתוח (בערך 3.6) בעוד הם חושבים שהם צריכים להיות פחות חלק ממנו (בערך 3.4).
  • ארכיטקטים מובילים את תהליך פיתוח התוכנה (3.1 = נטיה ל\"לא\"), אבל הם מאמינים שהם צריכים לעשות זאת (3.9)
  • הם גם משתתפים במידה רבה בישיבות תכנון (3.9) – אבל מאמינים שצריכים להיות שם הרבה יותר (בערך 4.35).
  • בגדול ארכיטקטים מאמינים שהם צריכים להיות:
    • שותפים משמעותיים יותר בפיתוח המקצועיות ומתודולוגיות הפיתוח בארגון.
    • שותפים משמעותיים יותר בהגדרת המוצר / חקר השוק.
    • שותפים משמעותיים יותר בגיוס עובדים.
  • מה הם חושבים שהם צריכים לעשות פחות?
    • קידוד: עושים לא-הרבה (3.1) – אבל רוצים לעשות פחות (3)
    • אחריות על באגים / תחזוקת-קוד: עושים מעט (2.6) – אבל רוצים לעשות משמעותית פחות (בערך 2.3).
ניתן לקרוא את התוצאות ולומר: \"ברור! כמו כולם הם רוצים להשפיע יותר, לעשות יותר עבודה כיפית – ופחות עבודה משעממת.\". אין לי מדד להשוואה למפתחי תוכנה – אבל אני מניח שהיינו רואים מגמות דומות.

בכל זאת, שימו לב שהשאלה לא הייתה \"מה הייתם רוצים לעשות\", אלא \"מה אתם חושבים שאתם צריכים לעשות (should do)\". אני מעריך (היפותזה) שמפתחים ותיקים לא היו חושבים שהם צריכים \"להנחות את הארכיטקטורה של כל פעילויות התכנון\" (\"Provide architectural guidelines for all software design activities\" – ההדגשה שלי) – עושים: 4.1, חושבים שצריכים: 4.37.

חשבו על הטיעון הלוגי הבא (שרץ כנראה במוחו של כל ארכיטקט תוכנה, בשלב כזה או אחר):
\"אם אני ארכיטקט\" וגם \"למוצר יש ארכיטקטורה\" => \"אני צריך להגדיר את הארכיטקטורה\".

הבעיה:

  • לכל מוצר תהיה ארכיטקטורה – גם אם אין ארכיטקט.
  • לא יעיל שאדם יחיד \"ישלוט בכל פרט בארכיטקטורה\" – עדיף שהארכיטקטורה תעשה ע\"י שיתוף פעולה. כאשר יש מי שיכול לתרום יותר (נאמר \"הארכיטקט\") – טוב שכך יהיה, שיתרום יותר.

השפה והמושגים בהם אנו משתמשים משפיעים על האמונות שלנו, ואני מאמין שלקרוא לתפקיד של כמה מאנשים על שם פעולה בה עדיף שיהיו כמה שותפים – היא פשוט לא מועילה.
ממש כמו שהשם QA הוא לא מוצלח – כי הוא מסיר אחריות מהמפתחים לאיכות הקוד שלהם. \"אני כותב – אתה אחראי לאיכות…\".

אני חושב שהייתי מעדיף שיקראו לארכיטקט Principal Engineer או System Engineer וכו\'…

הערה: לצערי אין לי את הנתונים לשתף (המחקר עוד בעבודה, והאמונים עליו לא מעוניינים לפרסם מידע חלקי).

Wix – להגיע ל n מליון משתמשים (n = כרגע 50 וקצת)
טוב… רציתי לגעת גם במצגת של יואב מ Wix – אבל גם רציתי לכתוב פוסט קצרצר.
אתם יכלים למצוא ביוטיוב את ההרצאה – בגרסה מעט יותר מוקדמת שלה.

כמה נקודות מעניינות שעלו:

  • אם Wix הייתה \"עושה ארכיטקטורה נכונה מהתחלה\" – היא לא הייתה שורדת את השנים הראשונות.
  • רכיבים במערכת צריכים להיכתב לתקופה קצובה – ואז להיכתב מחדש (טיעון מקובל בעולם ה Micro-Services). כתבו קוד שיהיה קל-להחלפה.
  • לא זקוקים לבסיס נתונים NoSQL בכדי לעשות NoSQL. עברתי, בזמנו, חוויה דומה – וכתבתי על כך פוסט.
  • כל מפתח מחזיק הרשאות ל production servers – אנו מעסיקים רק את מי שאנו סומכים עליו (אני מתרגם זאת לעצמי: אנו לא סומכים על אף-אחד, בנינו תשתית מתאוששת-עצמית – ולכן אנו יכולים \"לסמוך על כולם\"). זו גישה דיי מקובלת בעולם ה CD.
  • ההעדפה של Wix ל Managed Data Center (דוגמת Rackspace – אני לא יודע עם מי באמת הם עובדים) על פני AWS – שם כמות המשתנים הבלתי ידועים / נשלטים (למשל: מה החומרה שלי, latency) – היא קטנה יותר.
  • הערה: פרופיל השימוש ב Wix הוא דיי חריג בעולם ה Web (המון המון תוכן סטאטי) – ולכן אני מציע לשקלל עובדה זו בכל רעיונות Scalability שאתם לוקחים מהם.
כמו שאמרתי, Wix היא במיינסטרים של עולם ה Start-up Web ו CD.

סיכום

אם ישאלו אותי פעם בראיון עבודה על תוכנה לא טובה – הנה יש לי תשובה טובה: מתקשה לכתוב מעט טקסט 🙂
רציתי לשבת כעשר דקות ולכתוב משהו קטן – אבל הנה אני כותב כבר כמעט שעה.

שאלה: למה לא כתבתי על הכנס לפני שהתרחש – לידע קוראים מראש כשהוא עוד היה רלוונטי? – לא יודע, הייתי עמוס.

שיהיה בהצלחה!