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

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

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

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

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

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

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

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

אבל צום בתור תהליך מטבולי הוא לא אופציה תמידית במוקדם או במאוחר חייבים לאכול.

אבל

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

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

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

חלק ממודל חמשת השכבות הוא שכבת הגישה לבסיס הנתונים שכבה שבה כל המידע מיוצג באובייקטים במבנה בסיס הנתונים ושדרכו מתבצעות כל פעולות הגישה לבסיס הנתונים. לשכבה הזו שני רכיבים עיקריים: בסיסי ודינמי. הרובד הבסיסי מכיל בעבור כל טבלה מחלקה של מבנה הנתונים, שיטות INSERT לרשומה יחידה, שיטות UPDATE/DELETE לפי מפתח ושיטות SELECT לפי מפתח ראשי מלא או חלקי ומפתחות זרים. הרובד הדינאמי מכיל מחלקות שכל אחד מהם מייצג שליפה מורכבת ספציפית לצורך הצגה / דוחות.אבולוציונית את המודל הבסיסי ניתן לחזות במלואו מרגע שקיים מבנה הנתונים בעוד שהרובד הדינאמי נבנה תוך כדי מחזור החיים של האפליקציה.

מימוש

המימוש של שני הרבדים צריך לייצג את השוני הבסיסי בתפקודם בעוד שהבסיסי מכיל רשימת מלאי של מחלקות שכל אחד מהם מחולק לתפקודים כלליים שמממשים set, get, insert, update, select, delete. עקרונית ניתן לממש מחלקה אבסטרקטית שמממשת את כל הסט. הרובד הדינאמי מורכב ממחלקות עצמאיות שכל מחלקה מייצגת מודל נתונים מורכב ללא כל דמיון בין אחת לשניה. מומלץ למקם את שני הרבדים במרחב שמות אחד או כמרחבי שמות מקוננים. לדוגמא: afs.dal.base וafs.dal.custom
המימוש של הרובד הבסיסי צריך להיות מחולל

חילול DAL

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

נתונים נדרשים

לצורך חילול מחלקה אוטומטי נדרשים הנתונים הבאים:

• שם הטבלה – יהפוך לשם המחלקה
• שדות וסוגם – יהפכו למאפיינים במחלקה
• מפתח ראשי – ישמש ליצירת שיטת DELETE/UPDATE/SELECT ובמידה וכולל מספר שדות, גם לSELECT מדורג

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

שם טבלה: departments

המחלקה שתיוצר תכיל את המאפיינים הבאים:

ניתן לייצר שיטה של אתחול כללי או לייצר בנאי שמקבל כפרמטרים את המאפיינים:public departments (int _id, int _parentid, string _depname)
כמו כן אם כבנאי או כשיטה עצמאית תחולל שיטת SELECT שמקבלת את המפתח בתור פרמטר: public bool selectByKey(int kid, int kparentid)
שיטות הINSERT, UPDATE והDELETE תוגדרנה ללא פרמטרים : public bool insert(), public bool delete(), public bool update()
ממבנה הנתונים ניתן גם לחלל שיטה נוספת על שיטת הSELECT לפי מפתח :public int selectByParentId(int parentId,ref int[] id, ref string[] dep_name)

השיטות

מאחורי כל שיטה שאוזכרה למעט הבנאי או המאתחל שפשוט מאתחלים את מאפייני המחלקה עומדת פקודת SQL עם פרמטרים כאשר בפקודות הINSERT, UPDATE, DELETE הן לוקחות משתנים מתוך המחלקה וקושרות אותן לפרמטרים לדוגמא: UPDATE departments Dep_name=? where ID=? And parentID=?; השיטה UPDATE תקשור את המשתנים הקיימים לפרמטרים בשאילתא, תבצע את השאילתא ותחזיר מחווה הצלחה בוליאני.
שאילתות הSELECT גם מכילות SQL שמכיל פרמטרים לקישור (מפתח מלא או חלקי) אבל לאחר הביצוע כותבות את המידע המתקבל לתוך משתני המחלקה או מערך של ערכים.

כל השיטות הללו מחוללות על סמך האינפורמציה ששאבנו מבסיס הנתונים בלבד.

נקודות חשובות:

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

* במצבים כאשר ישנם ערכים המוגדרים על ידי טריגרים הנתונים שנמצאים במחלקה אינם מדוייקים אחרי הפעלת INSERT או UPDATE ולכן מומלץ בסוף ביצוע השיטות הללו להפעיל שיטת selectByKey על מנת לשמור על המידע שנמצא במחלקה עדכני.

* שיטת INSERT לעיתים תדרוש דבר נוסף, במספר בסיסי נתונים ניתן להגדיר(IC) IDENTITY Columns שדות שהערך שלהם נקבע בעת הכנסת הרשומה. כל עוד הערך אינו חלק מהמפתח, הפעלת selectByKey תשמור על המחלקה מסונכרנת עם בסיס הנתונים. כאשר הנתון שהוא IC הוא חלק מהמפתח נדרש טיפול קצת שונה: לאחר פעולת הINSERT מתבצעת שאילתא נוספת המגלה את ערך השדה שהוגדר כIC ומעודכן.

אפשרויות חילול קוד

הדרך הפשוטה ביותר לחלל את הקוד לDAL היא לכתוב קובץ במבנה של תוכנית ואז ידנית לקמפל אותה. מתודה זו תעבוד בכל שפת תכנות או סביבה. בסביבת הדוט נט קיים לFRAMEWORK מרחב שמות מיוחד שמאפשר לעשות משהו אחר קצת. ספריית ה CODEDOM מאפשרת לחולל את הקוד כמחלקה וכשכזו כבר לקמפל ולקשר אותה לידי DLL ולידי ומלא.

GSS

The acronym GSS stands for Global State Services. Globally available service which employs a proprietary protocol which enables any licensed application to switch state between devices seamlessly and securely. The service is deployed using standard web services which enable any web enabled device to communicate with it using XML over HTTP.

Usability

Platform and content independent you can use the GSS services to transfer your state to any supported device, mobile or stationary. Any game, form or application can be restored to any capable device. A game invoked on your tablet can simply switch to a friend’s smart TV miles away. A smart form can be edited on a supplier’s desktop, digitally signed by a client in the other side of the globe and transferred back to the supplier’s dispatch centre in a different continent. Similarly the same mechanism can be used to control global web application load balancing.

GSS implementation

Any application may register with the GSS services, enabling it to persist across devices. All that is required is for the application to pack its state using the GSS format, transmit it to the GSS service using the GSS protocol, message the target device using the GSS handler and the state is restored to the target device.

The GSS components

The GSS vision is comprised on three main components

The GSS protocol

The GSS protocol is a form of transferring free form state in and out of the GSS cloud. The simple protocol is based on web data standards (XML) and is built in two sections:

The GSS section which includes a single use token and target application
The State section which is any well-formed XML
Any registered application will be supplied with a strong secured identification which is transmitted securely over https to identify the target application and a public unique identification which will be used when communicating with the target device. Every GSS invocation creates a unique single use token which is used to identify the individual state. Once a state has been pulled the token is invalidated

The GSS message

The GSS message is the carrier which identifies the target device that a state is available for a specific application. Only the target application’s public credentials are transferred alongside with the unique token. Once invoked on the target device, the application identifies itself to the GSS cloud in the secured hidden manner and receives an handle to pull the individual state.

The GSS cloud

The GSS cloud is approachable using standard web methods. Any call to the GSS cloud must include the application registered credentials and may be a push or a pull call.

Push Calls

A push call uploads an individual state to be stored as an encrypted stream of well-formed XML waiting to be pulled; the only return value is the one off token.

Pull Calls

A pull call requests a specific token for a specific application; the token’s validity and context are validated and once validated the token is destroyed and the target application receives a download handle. Once the download is completed, the state is nullified.