如何有效實施新住民語文教育?若學校每週只教40分鐘,還不如邀新住民父母入課堂

如何有效實施新住民語文教育?若學校每週只教40分鐘,還不如邀新住民父母入課堂
國小越語自製教材。Photo Credit:張雅樑

我們想讓你知道的是

新住民語文的核心目標是要讓小孩認同家庭,幫助他們喜愛母語,而不是工具式地訓練他們成為外語專家。如果一星期在校只能接觸40分鐘的新住民語,還不如邀請新住民父母進入課堂,教孩子唱童謠、說故事、做童玩、做點心,讓小朋友更愛他的父母,願意開口說母語,這比任何的考試、拼讀和讀寫,都來得有益處。

「1998年我剛來台灣的時候,感覺上大家根本不知道印尼在哪裡,還有人問我說:『你是不是住在樹上?』我也不知道怎麼回他,因為我印尼的家可能比問我的那個人的家大很多倍,我不想正面跟他們爭辯,加上那時候有關東南亞的資訊真的不多,所以我在幫新住民小朋友上課時,我能夠同理他們的心情,也會跟小朋友分享我的經驗,希望他們不要有低人一等的感覺,我覺得文化是平等的。像我自己很認真,也考上公務員,就是一種證明,也給新住民的孩子一點信心,在學習上我們一點都不差。」

上述是我2015年進行新住民語文教育調查時,針對新住民二代教師A所進行的訪談,所謂「新住民語文」是國內對新住民母國官方語文的統稱,由於我國東南亞新住民人口不少,因此教育部便以「新住民語文」指稱東南亞移民的語言,並將越語、印尼語、泰語、柬埔寨語、緬甸語、馬來語和菲律賓語等7國語文列入十二年國教新住民語文課綱,規定新住民學生每週上一堂新住民語文課,學習讀說聽寫。

教育部於中小學推行新住民語文,立意良善,有助於實施全人教育,但課綱的內容與做法值得商榷,主要是現階段新住民語文教育出現了幾個互為因果的問題,必須釐清:

  • 需求上,為什麼要推行新住民語文教育?
  • 定位上,新住民語文教育屬於母語課程還是外語課程?
  • 做法上,如何有效實施新住民語文教育?

首先,為什麼要推行新住民語文教育?目的是想幫助新住民融入台灣社會。

我們的生活周遭經常會碰到新住民,但他們不見得願意說自己是「新住民」,因為這個名詞隱喻了某種標籤,有些人不明白「新住民」的意義,有些人則認為這個稱號會讓自己遭受歧視。

國內談論新住民議題已有好長一段時間,「新住民」一詞最早見於1990年代,之後台灣社會曾在不同階段用「新住民」這個語詞指涉不同對象,其中最鮮明的人物就是指稱外籍配偶(簡稱外配),像2004年台北縣(今新北市)政府所訂定的「新住民教育輔導計畫」中,就是用「新住民」一詞取代早期的「外籍配偶」用語,目的是要去除當時社會上對外配的負面意象(如假結婚、婚姻仲介等),以加強「我們都是一家人」的施政理念。

後來,國內各機關依例沿用,並將「新住民」與「外籍配偶」劃上等號,像〈新住民發展基金收支保管及運用辦法〉第1條明訂新住民為:「台灣地區人民之配偶為外國人、無國籍人、大陸地區人民及香港、澳門居民者。」但事實上,國內的新住民族群不只外配,舉凡持有外僑居留證、永久居留證,申請入境停、居留及定居我國的移民及其後代,包含外配、移工、留學生和新住民二代等,都可視為廣義的新住民。

這群人跟一般途經或短期造訪台灣的觀光客不同,他們不一定歸化中華民國國籍,但其工作、學習與婚姻狀況已然對台灣社會發揮或大或小的影響,其人數甚至超過原住民族,成為國內閩南、客家、外省之後的第4大群體,特別是新住民二代已漸成長,二代中又以東南亞裔為多,所以為顧及新住民教育權,也為推行新南向政策,教育部在十二年國教中,從善如流地將新住民語文納入課綱,搭配師培並編纂教材,正式在國中小啟動新住民語文教育,規定新住民小朋友必須在校學習新住民語文,這是國內推行新住民語文的發展背景與原因。以社會需求面而言,新住民語文教育就是實踐新住民教育權的一種形式。

理解需求背景後,再來討論定位問題,新住民語文教育究竟是母語課程還是外語課程?這是個關鍵提問,目前十二年國教課綱上的問題都來自於此,由於課程的定位不明,導致後續的課綱內容、教材設計、課程實施與師培都出現問題,形成連串的骨牌效應。新住民語文是「外語」,也是東南亞新住民的「母語」,因此國內對於新住民語文的定位一直游移在「外語」和「母語」之間,從〈十二年國民基本教育課程綱要語文領域—新住民語文〉(2018年版)內容看來,更偏外語多一些,這可由課綱內容看到其間的矛盾點。

¹Ï1_°ê¤p¶V»y½Ò¤W½Ò±¡§Î
Photo Credit:張雅樑
國小越語課上課情形,攝於台灣某國小

以國小新住民語文為例,其教學人員的聘任現況、課程實施方式與教育目的都與本土語文教育的做法幾乎相同,課綱規定新住民語文一週上一堂課,並提及:「學生是否在家使用該語言會使學生在新住民語文的學習起始點有很大的差異」,明顯視新住民語文為新住民學生的母語,此母語教育的導向就學生而言是正確的。

不過問題出在後續的學習內容上,因為課綱將新住民語文按能力指標分成4級,除了「聽」、「說」外,還要求「讀」、「寫」。學習「讀」、「寫」這件事,不太適合台灣的國小學童,因為在台灣小學學泰文和在泰國小學學泰文是兩種情況,泰文不是台灣的官方語言,所以我們不需要用學國語的方式來學泰文,也就是說國小階段的新住民語文並不需要側重「讀」、「寫」。

既然如此,那為什麼十二年國教課綱會一貫地要求聽說讀寫呢?那就是一種外語思維的設想,所以才會形成新住民語文課程定位上的矛盾,特別彰顯於國小階段,國小的新住民語文課是在母語課程上,設定了外語基礎課程的配備,才會要求學生讀說聽寫,樣樣都來。要釐清的是,學習外語需要聽說讀寫,但母語不用,當母語進入「讀」、「寫」的學習模式後,代表它是一種技能,需要記憶與考試,這和將母語當成是一種溝通的本能學習,是完全不同的教學設計。

國小新住民語文的實施難點不只如此,在中英雙語教育下,新住民語文(包含其它母語)早就是校內的邊緣課程,一週一堂母語課,到底能學什麼「讀」、「寫」?試想,在現有課綱的引導下,三語教育(中、英、新住民語文)全塞在小學生的頭腦裡,令人不忍又不解,為什麼我們的教育體制那麼愛考試、評鑑與規範?為什麼就不能讓小朋友快樂學母語?

¹Ï2_·s¦í¥Á»y¤å§@·~ï
Photo Credit:張雅樑
國小新住民語文作業簿

新住民語文的核心目標是要讓小孩認同家庭,幫助他們喜愛母語,而不是工具式地訓練他們成為外語專家。如果一星期在校只能接觸40分鐘的新住民語,還不如邀請新住民父母進入課堂,教孩子唱童謠、說故事、做童玩、做點心,讓小朋友更愛他的父母,願意開口說母語,這比任何的考試、拼讀和讀寫,都來得有益處。一旦小朋友願意說母語,可以自在聽、說後,有興趣的學生自然會繼續朝外語的方向深入學習該語言的讀、寫,這是新住民語文從母語轉向外語的自然過程,所以在小學階段,理應以母語教育為定位,養成學童聽、說能力即可。


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡