Уже доступно! Исследование Telegram 2025 — ключевые инсайты года 
ToCode
Открыть в Telegram
1 419
Подписчики
Нет данных24 часа
Нет данных7 дней
Нет данных30 день
Архив постов
1 419
# מדריך קוד: שליפה מבסיס נתונים ב Node.JS והצגת המידע כטבלא ב HTML
בפוסט זה אדגים איך לכתוב אפליקציית Node.JS ו Express פשוטה, ששולפת מידע מבסיס נתונים באמצעות ספריית Knex.JS ומציגה אותו בתור טבלה ב HTML. חסרי הסבלנות ביניכם מוזמנים לדלג על ההסבר ולקפוץ ישר לקוד במאגר:
https://github.com/ynonp/node-knex-ejs-demo
לכל השאר - בואו נראה איך זה עובד.
## מה אנחנו בונים
המשימה במדריך הזה מאוד פשוטה - יש לנו אפליקציית Node.JS שמשתמשת ב Express וב EJS. אני יודע כולם רגילים לראות ריאקט ו Ajax ופריימוורקס מתוחכמים של פרונט אנד, אבל האמת שיש הרבה אפליקציות בעולם שעדיין כתובות בגישה הקלאסית של יצירת HTML בצד שרת, כולל אפליקציות חדשות.
בכל מקרה המערכת בדוגמה שלנו היא כזאת - יש לה EJS View שנראה בערך כך:
<!DOCTYPE html>
<html>
<head>
<title><%= title %></title>
<link rel='stylesheet' href='/stylesheets/style.css' />
</head>
<body>
<h1><%= title %></h1>
</body>
</html>
sqlite> select * from users;
user|user@mysite.com
admin|admin@mysite.com
info|info@mysite.com
sales|sales@mysite.com
const knex = require('knex')({
client: 'sqlite3', // or 'better-sqlite3'
connection: {
filename: "./mydb.sqlite"
},
useNullAsDefault: true,
});
module.exports = knex;
routes/index.js. קוד זה צריך לשלוף את המידע מבסיס הנתונים. כל עוד אנחנו יודעים שאין הרבה מידע אפשר להשתמש ב:
router.get('/', async function(req, res, next) {
const users = await knex('users').select('*');
res.render('index', { title: 'Express', users: users });
});
<!DOCTYPE html>
<html>
<head>
<title><%= title %></title>
<link rel='stylesheet' href='/stylesheets/style.css' />
</head>
<body>
<h1><%= title %></h1>
<p>Welcome to <%= title %></p>
<p>All users = <%= JSON.stringify(users) %></p>
<table>
<thead>
<tr>
<th>Name</th>
<th>Email</th>
</tr>
</thead>
<tbody>
<% for (user of users) { %>
<tr>
<td><%= user.name %></td>
<td><%= user.email %></td>
</tr>
<% } %>
</tbody>
</table>
</body>
</html>
const result = await knex('persons')1 419
# היום למדתי: הסימן נקודותיים סלאש בגיט
לכבוד פסח, קבלו טיפ גיט קצר שאני גיליתי לאחרונה ואולי יעזור גם לכם - והוא הסימן נקודותיים ואחריו לוכסן.
משמעות הסימן היא התיקיה הראשית בפרויקט, והוא מאפשר לנו להריץ פקודת גיט על התיקיה הראשית גם אם כרגע אנחנו בתוך איזושהי תת תיקיה.
דוגמאות? בטח-
נניח שאתם רוצים לראות את כל הקבצים שגיט עוקב אחריהם במאגר, אבל אתם כרגע בתוך תיקיה פנימית. אתם כותבים:
$ git ls-files
$ git ls-files :/
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: ../agenda.md
Untracked files:
(use "git add <file>..." to include in what will be committed)
./
../react-list/
no changes added to commit (use "git add" and/or "git commit -a")
agenda.md שנמצא בתיקיה מעליי השתנה וגם התיקיה react-list שנמצאת בתיקיה מעליי אינה שמורה בגיט.
במצב כזה אני יודע שאני יכול להפעיל add על התיקיה שבדיוק מעליי כדי להוסיף את שלושת הקבצים, אבל ככל שהשינויים יהיו מפוזרים ביותר תיקיות זה אולי יהיה מסובך. במקום זה אני מפעיל:
$ git add :/
1 419
ייתרון ראשון שאנחנו רואים בהתקנת git-lfs הוא שפעולות add ו commit הופכות להרבה הרבה יותר מהירות. הסיבה היא שגיט מנסה לכווץ קבצים שהוא מכניס למאגר, וכיווץ קובץ בינארי ענק הוא פשוט בזבוז זמן. עם git lfs אנחנו חוסכים את הבזבוז הזה.
ייתרון שני ואולי יותר מלהיב הוא האפשרות לעשות clone למאגר בלי הקבצים הגדולים. הפקודה:
$ GIT_LFS_SKIP_SMUDGE=1 git clone https://github.com/ynonp/large-files-with-lfs.git skip-smudg
e
$ cd skip-smudge
$ du -sh .
140K .
$ cat myfile.bin
version https://git-lfs.github.com/spec/v1
oid sha256:fc4d5fa4f28329049cb1c1bdda562a7e6aa3472efbf94cc280f1f2aa9c6790a5
size 104857600
$ git lfs pull
myfile.bin ולא את שני העותקים שיש במאגר.1 419
# מדריך: איחסון קבצים גדולים בגיט עם git lfs
כולם אומרים שגיט לא טוב באיחסון קבצים בינאריים. בפוסט זה אני רוצה להסביר קצת מה הבעיה של גיט עם קבצים בינאריים גדולים, ולהראות את התוסף git lfs שפותר חלק גדול מאותה בעיה.
## החיים עם קבצים גדולים
הדרך הכי קלה (וברובה נכונה) לחשוב על ניהול המידע של גיט היא שכל קומיט בגיט הוא עותק של כל תיקיית העבודה ברגע מסוים. בתוך ההקשר הזה ברורה הבעיה עם קבצים גדולים - הם נשמרים שוב ושוב ומנפחים את המאגר.
ניצור בשביל הדוגמה מאגר עם קובץ גדול. אני מפעיל את הפקודה:
$ dd if=/dev/random of=myfile.bin bs=1m count=100
myfile.bin בגודל 100 מגה. אחרי זה אני יוצר מאגר גיט ומוסיף את הקובץ למאגר ו-הופ, הפרויקט שלי תופס כבר 200 מגה - כי יש לי עותק אחד של הקובץ הגדול בתיקיית העבודה ועותק נוסף במאגר בתיקיית .git. אם אני יוצר גירסה נוספת של הקובץ ומוסיף גם אותה למאגר התיקיה תעבור כבר את ה 300 מגה.
זה אומר שכשאני דוחף את המאגר לגיטהאב אני צריך להעלות 300 מגה. כשמישהו אחר מוריד עותק של המאגר הוא צריך להוריד 300 מגה. וככל שיהיו יותר גירסאות לקובץ הגדול, כך הגודל של המאגר יגדל וכל הפעולות יהיו איטיות בצורה מורגשת.
## אז מה זה git lfs
התוסף git lfs עושה דבר חמוד - במקום לשמור את הקבצים הגדולים במאגר, הוא מזהה אותם בדיוק לפני שהם נכנסים למאגר ומעביר אותם לתיקיה אחרת, שאינה חלק מהמאגר. בתוך הריפו יישמרו רק מצביעים לאותם קבצים, ומי שירצה את הקבצים הגדולים יצטרך להוריד אותם בנפרד.
התיקיה האחרת בדרך כלל תשב בתוך תיקיית .git ובשביל להזיז את הקבצים הגדולים לתיקיה המיוחדת git lfs משתמש ב filter, שזה מנגנון של גיט שמאפשר להריץ פקודה לפני שקובץ נכנס לריפו ופקודה אחרת כשהקובץ צריך לצאת מהריפו לתיקיית העבודה.
בשביל לעבוד עם git lfs אתם צריכים להתקין את התוסף לכל המערכת שלכם מהאתר שלהם:
https://git-lfs.github.com/
ואחרי זה בכל ריפו שרוצים לעבוד איתו צריך להפעיל בתוך תיקיית הריפו:
$ git lfs install
$ git lfs install
git lfs track. לקובץ שלי קוראים myfile.bin ולכן אני מפעיל:
$ git lfs track -f myfile.bin
-f) למשל:
$ git lfs track "*.bin"
.gitattributes אם לא קיים אצלכם בתיקיה (או מוסיף שורה לקובץ אם כבר קיים), ושם הוא מסמן שהקובץ או התבנית נכנסים למעקב:
$ cat .gitattributes
myfile.bin filter=lfs diff=lfs merge=lfs -text
$ git add myfile.bin
$ git commit -m 'initial commit'
$ dd if=/dev/random of=myfile.bin bs=1m count=100
$ git commit -a -m 'commit 2'
.git/objects שלי ממש קטנה:
$ du -sh .git/objects
32K .git/objects
$ du -sh .git/lfs/objects
200M .git/lfs/objects
$ git ls-files --stage -- myfile.bin
100644 e0ffbeb5780cceeeef67522f4bc092751c4e7409 0 myfile.bin
$ git cat-file blob e0ffbeb5780cceeeef67522f4bc092751c4e7409
version https://git-lfs.github.com/spec/v1
oid sha256:fc4d5fa4f28329049cb1c1bdda562a7e6aa3472efbf94cc280f1f2aa9c6790a5
size 104857600
1 419
# פוחדת מהפאדיחה ליפול
למתכנתים צעירים רבים אין בעיה לבוא בהצעות מרחיקות לכת, להכניס כלים חדשים ופריימוורקים חדשים למערכת ואפילו ליזום ולהעביר הרצאות על נושאים שהם כמעט לא מכירים. אותם מתכנתים מבינים את הפוטנציאל במוניטין שיוכלו לצבור, ויודעים שממילא אין להם הרבה מוניטין לאבד.
ככל שאנחנו גדלים המוכנות "לקחת סיכונים" נחלשת. הרווח שיצא לי מלהכניס כלי חדש למערכת הוא כנראה לא גבוה, והסיכון משמעותי. מתכנתת וותיקה עשויה להרגיש שמצפים ממנה להכיר לעומק כלי מסוים לפני שהיא ממליצה עליו לצוות; היא יודעת בדיוק מה זה אומר "להכיר לעומק" כי היא מכירה לעומק את הכלים שעכשיו עובדים איתם, ויודעת שכרגע (או בעתיד הנראה לעין) אין לה זמן ללמוד לעומק את אותו כלי חדש.
הפחד מהפאדיחה ליפול היה מה שעצר אותי כשכולם עברו מ perl ל python: ידעתי שכשאני מגיע ללקוח לעזור בבעיית פרל לא משנה מה יהיה אני אוכל למצוא לו פיתרון טוב, כי כבר ראיתי אינסוף בעיות פרל ופיתרונות שלהן באותה תקופה. ב python הסיפור היה שונה לגמרי - ההיכרות שלי עם פייתון היתה מוגבלת, ולפני שרואים פרויקטים ופותרים בעיות אי אפשר באמת לקבל ביטחון. פרילאנסרים צעירים ממני נכנסו בלי להתבלבל לפרויקטים בפייתון, ואני הסתכלתי מהצד וחיכיתי, וככל שחיכיתי הקפיצה רק נראתה יותר קשה.
הבעיה עם הפחד מהפאדיחה היא שבכל מקרה ספציפי ההחלטה לקחת סיכון היא באמת החלטה יותר קשה. מה טוב כבר יצא לי מלקחת פרויקט ייעוץ בפייתון כשאני לא יודע מספיק טוב פייתון? אני רק אשב המון שעות על כל בעיה קטנה, ובסוף אתן ללקוח קוד בינוני. אבל, כשמסתכלים על התמונה הגדולה, ברור שאחרי 3-4 פרויקטים אני כבר אכיר את השפה ממש טוב ואוכל להיות מועיל לעצמי ולסביבה.
וכשחוזרים לעבודה היום יומית כמתכנתת בצוות - להמליץ על כלי בודד שאולי לא יעבוד טוב זה מסוכן, אבל להיות זאת שממליצה על טכנולוגיות חדשות זה כבר משהו ששווה לשאוף אליו. העניין שהדרך תמיד עוברת דרך הפאדיחה, דרך הפעם הראשונה, דרך הנפילה.
במקום לפחד מהפאדיחה ליפול - כדאי להתרגל פשוט ליפול. להפוך את הנפילה לחלק מהחיים ולהבין שבטווח הרחוק, כשאנחנו בונים סגנון חיים שבו הנפילה היא לא פאדיחה אלא חלק מהיום יום שלנו, אנחנו רק מרוויחים.
1 419
# מה כל כך מלהיב ב Tailwind CSS
לפני כמה שנים לקחתי פרילאנסר לעזור בבניית HTML ו CSS לאתר שהייתי צריך ללקוח. הפרילאנסר עבד מעולה ויצר קוד שהתאים במדויק לעיצוב שהיה לנו, ואני הייתי בטוח שמצאתי את הדרך אל האושר.
עד שהיינו צריכים לשנות משהו.
כי הבעיה עם CSS היא שהכל תלוי שם בהכל: מאפיין של גודל גופן על אלמנט מסוים משפיע על הגופן אצל הילדים שלו, מאפיין position באלמנט מסוים משפיע על ההתנהגות של מאפייני top ו left אצל הילדים שלו. בקיצור CSS מרגיש כמו מגדל קלפים - זה עובד, אבל שינוי הכי קטן ודברים יוצאים מהמקום.
נשווה את זה ל Tailwind CSS, שהוא, לטובת מי מהקוראים שלא מכירים, פריימוורק שמעביר את ה CSS לתוך ה HTML, או אולי יותר נכון לנסח את זה בתור פריימוורק שיוצר דינמית הגדרות CSS שמתאימות לקלאסים עם שמות מאוד מסוימים ב HTML.
אז ב Tailwind CSS אני יכול לכתוב שורת HTML כזאת:
<img
src="http://placekitten.com/100/100"
alt="cat"
class="py-4 pl-4 aspect-square"
/>
1/1.
ומה כל כך מלהיב בלהעביר את כל כללי העיצוב ל HTML? אם נחזור לסיפור של הפרילאנסר, לתחזק קוד Tailwind CSS של מישהו אחר (בהנחה שאנחנו מכירים טיילווינד) זה הרבה יותר קל מלתחזק קוד CSS של מישהו אחר. אני לא צריך להיכנס ולהבין איזה קלאסים הוא בחר ומה המבנה ב HTML שמתאים לקוד ה CSS הקיים; הכל פשוט מופיע מול העיניים.
רוצים לדעת עוד על טיילווינד והקלאסים שלו? הפוסט הזה הוא מקום טוב להתחיל בו:
https://codingthesmartway.com/tailwind-css-for-absolute-beginners/
וכמובן התיעוד המעולה שלהם בקישור:
https://tailwindcss.com/docs/installation1 419
# קוד מלוכלך
דוד בוב אוהב לדבר על קוד נקי - קוד שאין בו חזרות, שמסודר נכון, שקל להרחיב אותו, שקל לקרוא אותו, שעושה בדיוק את מה שצריך ולא עושה דברים שלא צריך. כל אחד היה רוצה לכתוב רק קוד נקי כל הזמן.
אבל אם ניקח את המטאפורה של קוד נקי ברצינות, נשים לב ששום דבר לא יוצא נקי מהמפעל, ושעם הזמן גם דברים נקיים מתלכלכים.
ככה גם קוד: הניסיון הראשון בפיתרון בעיה לא ייצא נקי. אחרי הקידוד צריך לנקות, כלומר לעשות Refactoring, להוסיף תיעוד ולכתוב בדיקות. גם אחרי שעשינו את הכל כמו בספר, תוך כמה שבועות או חודשים הקוד יתלכלך שוב, בדיוק כמו כל דבר אחר בעולם.
קוד נקי הוא לא תוצאה של מתכנתים גאונים שיודעים איך לכתוב קוד, והוא לא תוצאה של שינון הכללים וניסיון ללכת לפי הספר. קוד נקי הוא תוצאה של גישה ושיטת עבודה. שיטה שמשאירה זמן ונותנת עדיפות גם לניקיון ולא רק לפיתוח הראשוני. קוד נקי הוא לא מצב קיים אלא תהליך, תהליך שמתחיל בקוד מלוכלך.
1 419
בתיקיית
src/app של הפרויקט תוכלו למצוא קובץ בשם store.js שמחזיק את התוכן הבא:
import { configureStore } from '@reduxjs/toolkit';
import memoryReducer from '../features/memory/memorySlice';
import memory from '../features/memory/memoryMiddleware';
export const store = configureStore({
reducer: {
memory: memoryReducer,
},
middleware: (getDefaultMiddleware) => getDefaultMiddleware().concat(memory),
});
configureStore, גם היא מ Redux Toolkit, מחזירה Redux Store לפי רשימת ה Reducers שתעבירו לה, ואת ה Reducer אני מייבא מהקובץ הקודם שכתבנו.
## קומפוננטת ריאקט
החלק הכי טוב בעבודה עם רידאקס הוא שכל הלוגיקה כבר קיימת בלי קשר לממשק, ולכן כשאני מגיע לכתוב קומפוננטת ריאקט אני בסך הכל צריך להבין איזה "מידע" משפיע על הקומפוננטה ואיזה פעולות היא יכולה לעשות.
במקרה של משחק הזיכרון המידע הוא רשימת הקלפים והפעולה היחידה היא ללחוץ על קלף. הנה הקוד של הקומפוננטה:
import React from 'react';
import { useSelector, useDispatch } from 'react-redux';
import {
play,
selectCards,
} from './memorySlice';
import './memory.css';
export function MemoryGame() {
const cards = useSelector(selectCards);
const dispatch = useDispatch();
return (
<div>
{cards.map((c, i) => (
<div
className={c.hidden
? "card hidden" : c.found
? "card found" : "card"
}
onClick={() => dispatch(play(i))}
key={i}
>
{c.value}
</div>
))}
</div>
);
}
const gameMiddleware = ({ dispatch, getState }) => next => action => {
// before play, if we're waiting for a "check" we'll
// cancel the timer, check immediately and then continue
// to play
if (action.type === play.type && activeTimer) {
clearTimeout(activeTimer);
activeTimer = null;
dispatch(check());
}
let result = next(action)
// after play we count 2 seconds and check the status
if (action.type === play.type) {
if (selectVisibleCards(getState()).length === 2) {
activeTimer = setTimeout(() => {
dispatch(check());
}, 2000);
}
}
return result
};
1 419
# מדריך קוד: בואו נכתוב משחק זיכרון ב Redux ו React
לפני שנתיים כתבתי כאן משחק זיכרון עם ריאקט בעזרת הפונקציה useReducer. היום אני רוצה לנסות משחק דומה עם Redux כדי לראות מה התחדש ברידאקס בשנים האחרונות ובמיוחד כדי לשחק עם Redux Toolkit, ספריה שהופכת את הכתיבה ברידאקס למשחק הרבה יותר מהנה.
## הסוד של רידאקס טולקיט הוא בכלל Immer
האמת חייבת להיאמר, כתיבת קוד JavaScript שמתעסק עם Immutable Data זה לא תענוג. אם אני צריך לקחת אוביקט סטייט שמורכב מאוביקטים פנימיים ולשנות משהו באחד האוביקטים הפנימיים שלו אני מהר מאוד מוצא את עצמי כותב דברים כאלה:
function handwrittenReducer(state, action) {
return {
...state,
first: {
...state.first,
second: {
...state.first.second,
[action.someId]: {
...state.first.second[action.someId],
fourth: action.someValue,
},
},
},
}
}
createSlice והיא בעצם יוצרת גם Reducer וגם Action Creators, משולבת עם Immer כך שהקוד שאני כותב בה "כאילו" משנה את האוביקטים.
בואו נצלול למשחק הזיכרון כדי לראות את הסיפור הזה בפעולה. כל הקוד שאני כותב עליו זמין בריפו הזה:
https://github.com/ynonp/redux-memory-game
אז במשחק זיכרון יש לי חבילה של קלפים שאני יכול ליצור עם:
const initialState = {
cards: _.shuffle(_.range(10).map(i => ({
value: Math.floor(i / 2),
hidden: true,
found: false,
}))),
};
function onPlay(state, action) {
const index = action.payload;
if (state.cards[index].hidden) {
state.cards[index].hidden = false;
}
const visibleCards = state.cards.filter(c => !c.found && !c.hidden);
if (visibleCards.length === 2) {
if (visibleCards[0].value === visibleCards[1].value) {
visibleCards[0].found = true;
visibleCards[1].found = true;
}
}
}
state.cards[index].hidden = false;
function onCheck(state) {
for (let c of state.cards) {
if (!c.found) {
c.hidden = true;
}
}
}
memorySlice.js ועד עכשיו לא היה שום דבר שקשור לרידאקס או ל redux-toolkit בקובץ. החלק האחרון הוא כבר נקודת הכניסה ל Redux:
export const memorySlice = createSlice({
name: 'memory',
initialState,
// The `reducers` field lets us define reducers and generate associated actions
reducers: { play: onPlay, check: onCheck },
});
createSlice מקבלת את שתי הפונקציות שכתבתי לתוך מפתח reducer של אובייקט הפרמטרים שלה ויוצרת גם Reducer מסודר וגם Action Creators. עכשיו אני יכול להשתמש בערך ההחזר שלה כדי לייצא את התוצאות:
export const { play, check } = memorySlice.actions;
export default memorySlice.reducer;
export const selectVisibleCards = (state) => state.memory.cards.filter(c => !c.hidden && !c.found);
export const selectCards = (state) => state.memory.cards;
1 419
# שאלה של גישה
לא מזמן דיברתי עם מתכנת ריאקט מאוד מוכשר, ששיכנע אותי בנאומים חוצבי להבות שהדרך הנכונה לכתוב קוד ריאקט היא להשתמש ב useEffect וב Custom Hooks כדי להעביר כמה שיותר לוגיקה, כולל לוגיקה של תקשורת, לתוך הקומפוננטות. הרבה יותר קל, הוא טען, לנהל את הלוגיקה של השליפות כשהשליפה קרובה לקוד שמציג את התוצאה שלה. בנוסף, כשאתה מוחק את הקומפוננטה אוטומטית אתה מוחק את קוד השליפה שקשור אליה, ולא נשאר עם מנגנוני שליפה שאף אחד לא משתמש בהם.
ואז מצאתי את המשפט הבא בתיעוד של Redux Toolkit:
> With RTK Query, you usually define your entire API definition in one place. This is most likely different from what you see with other libraries such as swr or react-query, and there are several reasons for that. Our perspective is that it's much easier to keep track of how requests, cache invalidation, and general app configuration behave when they're all in one central location in comparison to having X number of custom hooks in different files throughout your application.
בתרגום וקיצור הם אומרים שהם בנו את RTK Query כי הרבה יותר קל לנהל תקשורת כשכל הקוד שמתעסק בה נמצא במקום אחד.
"מי צודק" זאת בכלל לא השאלה כאן. הרבה אתגרים בתכנות בנויים ככה שאפשר לפתור אותם בכל מיני דרכים. כל גישה מגיעה עם הכלים שלה ובכל גישה אפשר לבנות פיתרונות טובים (או פחות טובים).
הדרך להיות מתכנתים טובים יותר היא לא למצוא את "הגישה האחת" שתמיד נכונה, אלא להיפתח ליותר גישות, ולהבין בתוך גישה מסוימת מה הסטנדרטים שמקובלים בה, מה זה אומר לכתוב קוד טוב (או גרוע) כשהלוגיקה בתוך הקומפוננטות, ומה זה אומר לכתוב קוד טוב (או גרוע) כשהלוגיקה נמצאת במקום אחר, ואיזה מלכודות או סכנות צפויות לנו בכל אחת מהגישות.
