Shadowing Practice: Every Networking Concept Explained In 20 Minutes - Learn English Speaking with Video
בחר מצב תרגול
כל מצב פותח חדר תרגול במסך מלא.
275 משפטים
אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.
1
In this video, I'm going to show you the essential networking concepts that every software engineer needs to understand.
2
We will follow a simple approach, basically watch how one application grows from a single server to a complex cloud system
3
and learn each networking concept exactly when it becomes necessary.
4
So meet Travel Buddy.
5
This is going to be our imaginary travel booking website.
6
and we will see how its networking needs evolved over time
7
and you'll understand why each networking piece exists and how it solves real problems.
8
We also created a detailed handout that breaks down everything that I'm going to cover today.
9
So make sure to grab it from the link below.
10
It's completely free.
11
So let's start at the beginning.
12
When we first launched Travel Buddy, we had one server running our entire application application.
13
Simple, right?
14
But immediately we faced our first networking question.
15
How do customers actually find our server on the internet?
16
Every device connected to a network needs an identifier so that other devices can send data to it.
17
And this identifier is called an IP address.
18
Think of it like a house address for mail delivery.
19
Without it, no one knows where to send anything.
20
So our travel body server got a public IP address, which looks like this.
21
This means any device on the internet can send a request to this specific number and reach our server.
22
Now you may be thinking, do I need to remember numbers like 203,
23
0, 100, 13, and 10 to reach a website?
24
No, just like you don't memorize phone numbers anymore, we don't memorize IP addresses either.
25
And this is where DNS comes in.
26
DNS translates easy to remember names into IP addresses.
27
So when someone types travelbuddy.com into their browser,
28
DNS automatically looks up the IP address that will look like this and connects them to our server.
29
DNS works like contacts in your phone.
30
not type in the phone number, the actual phone number.
31
You just tap on the name, like mom, and your phone finds the actual phone number in the background.
32
Just like you type google.com and DNS finds the actual IP address behind that name.
33
So now customers can find our server.
34
Good.
35
But here is the next problem.
36
Our single server is now running three different things.
37
the website that customers see, a database storing all the booking information, and a payment processing service.
38
All three share the same IP address.
39
So when the request arrives at our server, how will the server know which application should receive it?
40
This is where ports solve our problem.
41
Ports are numbered channels on a server, ranging from 1 all the way to 65,535,
42
and each application listens on a different port number.
43
So let's say this is how we set up our application.
44
The website listening on port 80, which is standard for web applications or for a secure connection,
45
there is a standard port for secure web application connections on port 443.
46
Then we have a MySQL database listening on port 3306.
47
That's a standard MySQL port.
48
And then we have some custom payment service that we decided to run on port 1990.
49
Now, when a customer visits travelbuddy.com, their browser automatically connects to port 80 or 443,
50
and the server knows to send the traffic to the web application and not to some other program on the server.
51
So think of it like apartment building.
52
The building has one street address, that's the IP address, but inside the building, there are different apartment numbers, like the ports.
53
Great, so that's taken care of.
54
But now, we're growing and a new problem appears.
55
Travel Buddy is now handling customer credit cards and some personal information.
56
And having everything on one server creates a big security risk for us and for our users.
57
Because if a hacker now broke into our server that runs all these applications, they get access to everything.
58
To the database, to the payment service, everything.
59
So we need to separate things.
60
This is called network segmentation.
61
And subnets let us divide our network into separate sections.
62
Think of it like a hospital that has different floors and wings for different types of patients.
63
like maternity ward on one floor, surgery on another to keep things cleanly separated.
64
We do the same with our network.
65
Let's say our front end servers, which are public facing go in subnet A, with this IP address range,
66
application servers going subnet two with this IP address range and database servers go in another subnet.
67
So now our network is divided.
68
But wait, if the website is in one subnet and the database is in another subnet, how does the website talk to the database now?
69
And this is where routing becomes necessary.
70
Routing directs traffic between different network segments.
71
When the website needs data from the database, the router will determine the path.
72
So it's basically like a GPS for network data.
73
It figures out how to get from point A to point B.
74
But now we have a new problem.
75
We've separated things into different areas, but what stops everything from talking to everything else?
76
We've created separate rooms, but all the doors are now wide open and unlocked.
77
Just because we can route traffic between subnets does not mean we should allow all traffic in all directions.
78
And that's where firewalls become necessary.
79
A firewall is like a security guard that checks every piece of traffic
80
and decides whether to allow it based on rules that we set.
81
We have host firewalls that protect individual servers.
82
So we put firewall on the database server and create a rule
83
that says only accept connections on port 3306 and only from IP addresses in the front end subnet.
84
Anything else gets blocked.
85
And we also have network firewalls that sit between subnets and filter traffic.
86
So we may place one between the internet
87
and our frontend subnet with a rule saying allow incoming traffic on port 80 and port 443,
88
but block everything else.
89
So if we have another program or application running in front of subnet on a different port, it will be blocked right away with this firewall rule.
90
So this layered approach means that an attacker has to get through multiple security checkpoints like the network firewall,
91
then the host firewall to actually do any damage because security is always layered.
92
With firewalls in place, we have now created secure zones in our network.
93
But another problem is about to appear.
94
Travel buddy is growing fast.
95
We now have 50 backend servers in a private subnet for security.
96
And these servers have private IP addresses like 10 0 2 5,
97
10 0 2 6, 10 0 2 7 and so on.
98
So private IP addresses work inside your own network, but they cannot communicate directly with the internet.
99
It's like having an internal extension number at the company.
100
You can call other extensions inside the building, but you can't dial an extension number from your home phone from outside the building, from your home office.
101
But our backend servers do need to reach the internet sometimes to download software updates,
102
to connect to external payment APIs maybe, or to send data to third party services.
103
So how do we solve this problem?
104
Because now we have them secured so that nobody can just directly reach them from internet, they cannot reach internet either.
105
And we can't give each server a public IP address because first public IP addresses cost money
106
and we need to manage them and we would now need 50 of them.
107
Well, that's where NAT or network address translation comes in.
108
So NAT basically allows multiple devices with private IP addresses to share one public address when accessing the internet.
109
So here's how it works.
110
When backend server 10.0.2.5 wants to reach an external website to let's say download updates for a database,
111
it sends a request to the net device.
112
The net device replaces the private source address with its own public IP address and sends the request out to the internet.
113
When the response comes back, the net device remembers all this response is meant for server 10.0.2.5 and sends it to the right place.
114
So think of it like a receptionist at an office.
115
When an employee needs to make an external call, they go through the company's main phone line.
116
The receptionist places the call using the company number and then routes the response back to the correct employee's desk.
117
So now all 50 of our backend servers can reach the internet through one public IP address.
118
So they remain hidden and protected, no direct access to them from internet, but they can still get what they want from outside.
119
At this point, we've built a solid networking foundation, but maintaining all these physical servers is becoming expensive and slow.
120
We're spending too much time managing hardware now.
121
We have to predict capacity month in advance.
122
We have to buy servers, install them, maintain them.
123
When we need more capacity, it just takes weeks to set them up.
124
So we decided to move TravelBuddy to cloud.
125
The cloud means we're renting computing resources instead of owning them.
126
So someone else manages the hardware and we can increase or decrease capacity in minutes now instead of weeks.
127
But here is an important part.
128
The networking concepts we learned do not change.
129
We still need IP addresses.
130
We still have ports on servers.
131
We still have subnets, routing, firewalls, and NAT.
132
The cloud just provides these as managed services.
133
So in the cloud, we create what's called a virtual private cloud or VPC.
134
And this is our own isolated section of the cloud providers network.
135
Think of it like renting an office floor in a large office building.
136
Other companies are on different floors, but your area is yours.
137
Nobody can enter your office, even though they're in the same building.
138
Inside our VPC, we create subnets just like before.
139
We still have public subnets for things that need internet access and private subnets for things that should be protected.
140
We use an internet gateway to connect our public subnets to the internet.
141
It's basically like a main entrance to our building.
142
We have route tables, which are like signposts
143
that tell the data where to go in our network
144
and each subnet has a route table
145
that directs traffic for private subnets we use net gateway remember
146
net from earlier it's the same concept just managed by the
147
cloud provider we place a net gateway in a public subnet
148
and configure the private subnets to route their outbound internet traffic through it
149
so now we have the same secure network architecture we built before
150
but running in the cloud with all the benefits of cloud flexibility
151
but our application is about to change again
152
but before we move on i want to give a huge shout out to polumi for making this video possible
153
so you just saw all the infrastructure we built in the cloud the vpc the subnets, the security groups and so on.
154
But here's a question.
155
How do you actually define and manage all of this infrastructure as code?
156
This is where Pulumi really helps because unlike other infrastructure as code tools that use their own domain specific languages,
157
Pulumi lets you use the programming languages that you already know like TypeScript, Python, Go, Java, whatever, that you're already using in your tech stack.
158
This means you can use your favorite IDE to write infrastructure code with all the features like error checking,
159
autocomplete, refactoring, debugging tools that you're already comfortable with.
160
And you can write real programming logic instead of being limited by the configuration syntax.
161
And here's what's really cool.
162
Pulumi just launched Pulumi Neo, which is their new agentic AI built specifically for infrastructure.
163
Neo understands your entire infrastructure setup, respects your policies, and it can handle complex tasks end-to-end.
164
So you can describe what you need in natural language, and Neo will generate the code,
165
review your pull requests, and even help you debug deployments with full understanding of your organization's infrastructure.
166
Palomi is open source, so you can use it for free.
167
But if you want the enterprise features, you can use my code,
168
NANA500, and you're going to get $500 worth of credits to test out those enterprise features.
169
I will leave the link in the description.
170
Now let's continue with the video.
171
As travel buddy grows, our application becomes more complex.
172
So we have more services, more dependencies, more things to install and configure.
173
And we also move to microservices architecture to make our application or scalable.
174
And managing our deployments is actually becoming more and more complex.
175
And we're increasingly running into it works on my development laptop, but not on the production server issues.
176
And this is where containers solve our problem.
177
A container packages everything an application needs, the code, the runtime, all the libraries and settings into one portable package.
178
So think of it like the difference between a food truck and a restaurant.
179
With a food truck, everything is already inside.
180
Just drive it somewhere and start cooking and serving your food.
181
Whereas restaurant, you have to find a place
182
and you have to set everything up and it's really difficult to move location
183
because you have everything tied up in that one restaurant.
184
So we use Docker to containerize all of the travel buddies services.
185
And now we can run the same container on a developer's laptop, on our test servers, in production, and it works almost identically every time.
186
But containers introduce new networking concepts that you need to understand.
187
When you run containers on a server, they need to talk to each other.
188
Docker creates something called a bridge network, a private network that exists only on that server.
189
connected to the same bridge network can actually communicate with each other using just the container names, but containers have their own private networking inside them.
190
When our payment service container runs, it might listen on port 1990, for example, inside the container.
191
So the question is how do external requests then reach that application running inside the container on port 1990?
192
Well, we need to map the containers internal port to a port on the host server.
193
So docker run command has a parameter that lets you bind
194
or map the port inside container to your host or server's port number.
195
So this tells docker take all the traffic
196
that arrives on this host server on port 1990 and forward it to port 1990 inside the container called payment.
197
Notice this is similar to the net concept that we learned earlier.
198
We're translating addresses and ports to bridge between two different networks.
199
Now, as we grow even more and we run containers on multiple servers now, because one server is not enough to run all our containers,
200
before all our microservices, we need them to communicate with each other across servers, not just on a single server.
201
So Docker's overlay network creates a virtual network that spans multiple hosts,
202
making containers on different servers appear as if they were on the same network.
203
So now with Docker, we've made our application portable and consistent.
204
But now we're facing a new challenge, which is managing hundreds of containers, which is absolutely quickly achieved when you have microservices application
205
that is running in multiple replicas or copies of the same service for scalability and performance.
206
And our travel buddy is successful, so we're running hundreds of containers across dozens of servers.
207
And managing this manually is becoming impossible.
208
Like which server should a new container run on?
209
What happens when a container crashes?
210
How do you troubleshoot when something goes wrong when you have hundreds of containers?
211
How do you even know that a container crashed
212
when you have hundreds of them how do containers find each other
213
when they keep moving around from one server to another
214
and this is where kubernetes comes into the picture
215
so kubernetes automates container management think of it like an automated building manager
216
that assigns apartments ensures everything is running and handles maintenance in kubernetes the basic unit is a pod.
217
A pod is a group of one or more containers that work closely together.
218
Usually it's just one container per pod and each pod gets its own IP address.
219
So think of a pod like an apartment unit.
220
The apartment has one address and everyone living in that apartment shares that address.
221
So all the containers inside a pod will share that same IP address.
222
But here's the problem pods are temporary kubernetes can create a
223
pod destroy it move it around create a new one at any time
224
when you do an update maybe a pod crashed maybe you were updating a version of the application
225
and each time kubernetes creates a new pod
226
that pod gets a new ip address so
227
if our website pod is trying to connect to our database pod
228
and the database pod gets recreated with the new ip address
229
the website pods connection breaks and pods are ephemeral
230
so we shouldn't rely on them being around for a long time
231
so how do we solve this problem well this is where
232
kubernetes services help us a kubernetes service provides a stable ip address
233
and dns name that never changes even as pods behind it come
234
and go so we create a service for each of our pods like our database pods
235
and service gets a permanent IP address and a DNS name like database service.
236
So now when our website pod needs to connect to the database, it connects to database service instead of connecting to a pod directly.
237
And the service automatically forwards the connection to one of the healthy active database pods.
238
If a database pod dies in the background and gets replaced with a new one, the service automatically updates.
239
And the website pod does not notice anything.
240
It's still connecting to the same database service.
241
It doesn't know what even happened in the background.
242
So think of it like a department phone number at a company.
243
You call the sales department number and it rings at someone's desk.
244
The person might change, but the department number stays the same and there will always be someone who will answer the phone.
245
And this is crucial in Kubernetes because pods are constantly being created and destroyed and services provide the stability that we need.
246
Now we need to expose our application to the internet.
247
We have multiple services running inside our cluster.
248
So we need to think how do external users actually reach our applications running inside the cluster?
249
Well, we use something called Ingress.
250
So Kubernetes Ingress is like a reception desk that routes visitors to the right department based on what they're asking for.
251
So a single Ingress can handle all incoming traffic into the cluster
252
and route it to the correct service inside the cluster based on the rules that we configure.
253
For example, we can say all the requests coming to travelbuddy.com go to website service.
254
All the requests coming to travelbuddy.com slash API slash booking go to the booking service.
255
Slash API slash payment request to that URL go to the payment service.
256
So let's recap what we learned by following Travel Buddy's journey.
257
We learned five basic foundational concepts of networking.
258
First of all, every device needs a unique identifier, which is an IP address, so others can find it and talk to it.
259
And DNS then translates human-friendly names to these IP addresses.
260
Second, multiple applications on the same server need different doors to listen on so that traffic goes to the right application.
261
So that's the concept of ports.
262
We need network segmentation where we divide networks into separate sections
263
or subnets for security and organization and routing then connects these sections.
264
We also need security in order to control what traffic is allowed between different network segments and to different ports.
265
So we need firewall concept for that.
266
And finally, when we secure our backend applications within private networks, We need them to still reach the internet directly.
267
So NET acts as a gateway, translating their private addresses to a shared public IP address to allow communication to the internet.
268
So these five concepts are the foundation of networking and whether you are working with physical servers, cloud infrastructure, Docker containers, or Kubernetes pods,
269
these principles actually remain the same.
270
So the tools change we went from physical routers to vpcs from physical firewalls to security groups
271
but the concepts never change so if you master these fundamentals
272
and you'll understand those basic networking concepts then you will understand any networked system
273
and you'll be able to troubleshoot optimize applications at any scale now
274
if this was helpful then share it with one friend
275
or colleague that you know will benefit from this video thank you for watching and I'll see you in the next one.
הורד אפליקציה
כל מה שאתה צריך כדי לדבר בשטף
הגיית AIציון לכל משפט
תרגול IPAשלוט בכל צליל
אוצר מיליםבנה את מאגר המילים שלך
משחק אוצר מיליםלמד תוך כדי משחק
אותו ערוץ
C1Redis Crash Course - the What, Why and How to use Redis as your primary database
Daily ConversationUniversity StudentsWorking Adults
C12
What is Docker? Docker container concept explained || Docker Tutorial 1
Daily ConversationUniversity StudentsWorking Adults
C12
NGINX Explained - What is Nginx
Business EnglishUniversity StudentsWorking Adults
B21
CI/CD Explained in 5 Minutes
Business EnglishUniversity StudentsWorking Adults
C12
Microservices explained - the What, Why and How?
Business EnglishUniversity StudentsWorking Adults
C17
If I would start DevOps from 0 - How would I start and what would I learn
University StudentsWorking Adults
C12
Kafka Tutorial for Beginners | Everything you need to get started
Business EnglishUniversity StudentsWorking Adults
FOR YOU
המלץ על סרטון
C11
176 משפטים
Every Networking Concept Explained | Networking 101 (2026)
Daily ConversationUniversity StudentsWorking Adults
C14
239 משפטים
My 4.9-Star iOS App Is Actually a Website: Here’s How I Built It
Daily ConversationUniversity StudentsWorking Adults
C11
54 משפטים
Traceroute: You're Probably Reading the Results Wrong
Daily ConversationUniversity StudentsWorking Adults
C13
81 משפטים
Everything You Need to Know About DNS: Crash Course System Design #4
Daily ConversationUniversity StudentsWorking Adults
C1101 משפטים
BGP Overview
Daily ConversationUniversity StudentsWorking Adults
C167 משפטים
The Ultimate IoT Roadmap in 2026? | Embedded Systems & IoT Career Roadmap
Daily ConversationUniversity StudentsWorking Adults
C11
9 משפטים
What is a Server? Servers vs Desktops Explained
Daily ConversationUniversity StudentsWorking Adults
C11
74 משפטים
LangChain in 5 Minutes (Explained Clearly)
Daily ConversationUniversity StudentsWorking Adults
C11
28 משפטים
Network Ports Explained
Daily ConversationUniversity StudentsWorking Adults
C1155 משפטים
Every Hardware Protocol Explained Simply in 10 Minutes!
Daily ConversationUniversity StudentsWorking Adults
C11
49 משפטים
Why Do You Need BOTH a MAC and IP Address?
Daily ConversationUniversity StudentsWorking Adults
אוצר מילים והערות הגייה לשיעור הזה
שיעור הדיבור הזה ברמה C1 מבוסס על הסרטון “Every Networking Concept Explained In 20 Minutes”. המילים שחוזרות הכי הרבה: server, container, port, pod, application. בסרטון הזה יש 275 משפטים ו-3500 מילים לתרגול Shadowing. הדיבור נמשך 23:20. הדובר מדבר בקצב טבעי של כ-150 מילים בדקה, קרוב לשיחה יומיומית. רק 80% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית, כך שאוצר המילים מאתגר.
אוצר מילים מרכזי בסרטון הזה
14 המילים המתקדמות ביותר בסרטון, עם ההגייה והמשמעות שלהן:
| מילה | הגייה | משמעות |
|---|---|---|
| container שם עצם | /kənˈteɪ.nəɹ/ | מיכל |
| translate פועל | /tɹænzˈleɪt/ | תִּרְגֵּם |
| memorize פועל | /ˈmɛm.əˌɹaɪ̯z/ | שִׁנֵּן |
| receptionist שם עצם | /ɹɪˈsɛp.ʃə.nɪst/ | פקיד קבלה |
| router שם עצם | /ˈɹaʊ.tɚ/ | נַתָּב |
| checkpoint שם עצם | /ˈt͡ʃɛkˌpɔɪnt/ | נקודת ביקורת, נְקֻדַּת בִּקֹּרֶת |
| ephemeral שם תואר | /ɛˈfɛ.mə.ɹəl/ | בֶּן חֲלוֹף |
| syntax שם עצם | /ˈsɪn.tæks/ | תַּחְבִּיר |
| imaginary שם תואר | /ɪˈmæd͡ʒɪˌn(ɛ)ɹi/ | דִּמְיוֹנִי |
| unlock פועל | /ʌnˈlɑk/ | פתח |
| colleague שם עצם | /ˈkɒliːɡ/ | עָמִית, עמיתה |
| flexibility שם עצם | /ˌflɛksɪˈbɪlɪti/ | גְּמִישׁוּת |
| stack שם עצם | /stæk/ | ערמה |
| shout פועל | /ʃaʊt/ | צעק, צרח |
Phrasal verbs שתשמעו
| מילה | משמעות |
|---|---|
| come back פועל | שָׁב |
| figure out פועל | הֵבִין, מצא תשובה |
משפטים שכדאי לחזור עליהם
משפטים קצרים ושלמים מהסרטון שאפשר להשתמש בהם בשיחה יומיומית:
- How do customers actually find our server on the internet?
- We're spending too much time managing hardware now.
- It's basically like a main entrance to our building.
דקדוק בסרטון הזה
המבנים שהדובר משתמש בהם הכי הרבה, עם המילים המדויקות מהסרטון:
| מבנה | בסרטון |
|---|---|
| סביל (Passive voice) be + past participle — הדגש הוא על מה שקורה, לא על מי שעושה את הפעולה | is called · is divided · will be blocked |
| משפטי זיקה (Relative clauses) who / which + clause — מידע נוסף על אדם או דבר | servers, which are · tables, which are · Neo, which is |
| הווה מושלם (Present perfect) have/has + past participle — פעולה שקרתה בעבר ועדיין יש לה חשיבות או השפעה עכשיו | We've separated · We've created · have now created |
הגייה ששווה לשים לב אליה
הדובר משתמש ב-28 קיצורים וצורות מקוצרות, כמו we're, we've, you'll. אמרו אותם בצורה הקצרה, כפי שאתם שומעים אותם.
- הצלילים של “sh” ו-“zh”: receptionist /ɹɪˈsɛp.ʃə.nɪst/, troubleshoot /ˈtɹʌbl̩ˌʃuːt/, foundational /faʊnˈdeɪ.ʃə.nəl/, configuration /kənˌfɪɡ.əˈɹeɪ̯.ʃən/, shout /ʃaʊt/
- מילים ארוכות — שימו לב להטעמה: receptionist /ɹɪˈsɛp.ʃə.nɪst/, ephemeral /ɛˈfɛ.mə.ɹəl/, foundational /faʊnˈdeɪ.ʃə.nəl/, identically /aɪˈdɛntɪkəli/, dependency /dɪˈpɛndənsi/
צלילים שדוברי עברית מתקשים בהם:
- /w/ — שפתיים מעוגלות, לא /v/: firewall /ˈfaɪ(ə)ɹˌwɔl/, gateway /ˈɡeɪtˌweɪ/
- /æ/ — פתוח יותר מה-“אֶ” העברית, לא כמו “a” ב-“cup”: translate /tɹænzˈleɪt/, handout /ˈhændˌaʊt/, syntax /ˈsɪn.tæks/, parameter /pəˈɹæm.ə.tɚ/, attacker /əˈtækɚ/
- /r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: container /kənˈteɪ.nəɹ/, firewall /ˈfaɪ(ə)ɹˌwɔl/, translate /tɹænzˈleɪt/, configure /kənˈfɪɡə(ɹ)/, memorize /ˈmɛm.əˌɹaɪ̯z/
איך לתרגל עם הסרטון הזה
- הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
- התחילו במהירות 0.75×, תרגלו Shadowing משפט אחר משפט, וחזרו למהירות רגילה כשזה מרגיש קל.
- הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו container, translate, memorize.
מהי טכניקת השאדואינג?
שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.