Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

一起來做英文文章閱讀練習吧! #2

Open
maoyang opened this issue Jun 14, 2016 · 17 comments
Open

一起來做英文文章閱讀練習吧! #2

maoyang opened this issue Jun 14, 2016 · 17 comments

Comments

@maoyang
Copy link
Contributor

maoyang commented Jun 14, 2016

昨天與這邊的一位網友 @willard1218 聊了一下, 他前幾天在slack general分享一篇他翻譯的文章 Mastering Programming , 他是受到一位網友的另一篇文章去做了這件事 [討論] 大家如何習慣看英文資料???

@willard1218 也建議Soft & Share應該要建立一個channel, 讓有興趣練習翻譯國外文章的網友加入組成一個社團, 我看了willard 分享的文章後, 覺得這個活動很有意義, 因為我發現到大部分的人確實不太有習慣看原文(包括我在內 XD ) , 但是以資訊人來說, 看原文這個技能是必要的, 第一手的資訊就是英文, 所以感謝willard的建議讓我興起了辦這個meetup的念頭

meet up channel 功能

大家可以在channel中分享目前在看的一些原文文章, 或是翻譯練習, 不懂的地方也可以互相討論

參加這個meet up條件

隨意認領一句話 (不一定要照順序,挑你喜歡的就好),試著自己
讀、解析句型、理解、會意、翻譯

  • 建議程度: 已知國中英文文法、能自行查英中/英英字典者
  • 儘可能不要依賴機器翻譯
  • 重點在於了解整句的文法、文意;專有名詞無須硬翻

請要加入這個meetup的網友寫下你翻譯的句子(包括原文出處), 附上你的slack id, 我就會將你加入這個private meetup

@jawayang
Copy link

jawayang commented Jun 14, 2016

If you fail to do this, you will fail. 如果你無法達成這些,你將會失敗。 @jawayang

@maoyang
Copy link
Contributor Author

maoyang commented Jun 14, 2016

@jawayang 這句話出自那篇文章 ?

@jawayang
Copy link

@maoyang
Copy link
Contributor Author

maoyang commented Jun 14, 2016

@jawayang Sorry, 不能拿別人翻譯好的句子

@jawayang
Copy link

書名:the-way-of-the-web-tester
第ix頁
內容:It’s an important topic because automated testing is the one of the greatest levers we’ve got for giving people back the one thing we all seem to need more of on software projects—time.
More time to add more features. More time to be creative.
More time to have fun!
這是一個重要的議題,因為自動化測試是一個很重要的控制桿,它可以讓人們獲得軟體專案中最重要的一個東西 - 時間。
更多的時間去增加更多的功能
有更多的時間去創造
有更多的時間玩樂

@maoyang
Copy link
Contributor Author

maoyang commented Jun 14, 2016

@jawayang Great 已經將你加入meet up channel

@papalun
Copy link

papalun commented Jun 14, 2016

The Need to go Reactive
Applications, especially on the web have changed over the years from being a simple static page, to DHTML with animations, to the Ajax revolution. Each time, we're adding more complexity, more data, and asynchronous behavior to our applications. How do we manage it all? How do we scale it? By moving towards "Reactive Architectures" which are event-driven, resilient and responsive. With the Reactive Extensions, you have all the tools you need to help build these systems.

為什麼需要 Reactive
這些年來 Application 都不斷在改變,特別是 web,從一個靜態網頁到有動畫的 DHTML,再到 Ajax 革命。每一次的改變,都增加了更多的複雜性、資料與非同步的行為到我們的應用程式。我們應該如何管理這一切?如何擴展(scale)它?透過「Reactive Architectures」 一個事件導向、具有彈性、響應式的架構,搭配「Reactive Extensions」,你將擁有建構這些系統的工具。

文章出處:https://github.com/Reactive-Extensions/RxJS

@allen.hsieh

@maoyang
Copy link
Contributor Author

maoyang commented Jun 14, 2016

@papalun Thank you 已經邀請你加入了

@ryan119
Copy link

ryan119 commented Jun 14, 2016

Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time.

設計模式代表由經驗豐富的物件導向軟件開發人員使用的最佳實踐。設計模式是軟件開發人員在軟件開發過程中面臨的普遍問題的解決方案。這些解決方案長期經由眾多軟件開發商得到試驗和錯誤。

文章出處 : https://hunterhan.gitbooks.io/design-patterns-in-java-tutorial/content/chapter1.html

@ryanchung

@tsengeagle
Copy link

Everyone benefits a great deal when the applications we create actually work.
Failure in production is expensive, we should do our best to minimize that.
With today’s technology, reach, and visibility, when applications fail the entire
world can take notice. With automated tests, we can fail fast and safely, and
in the process create resilient applications that work well in production.

當我們建立的應用程式真的上線時,人人都能受益
但是當系統在生產環境故障的時候,代價是昂貴的。我們應該盡最大努力來避免系統故障。
透過現今的技術,當應用程式故障的時候,全世界不但能留意到,並且可以『接觸到』,『看到』系統的狀況。
化測試,我們可以更安全更快速的去測試系統,並且創造出更有彈性的應用程式。

出處:
Test-Driving JavaScript Applications
第一章 Automation shell set you free
第19頁

@cosecantTW
Copy link

cosecantTW commented Jun 14, 2016

預測式學習,也可以稱為非監督式學習,是動物和人類了解這個世界的主要模式。
例如這個句子:"約翰拿起了電話並且離開了房間"。經驗告訴你這支電話可能是一支行動電話,並且約翰應該是從門離開房間的。 一台機器若是缺乏對整個世界的表象以及諸多限制的理解,永遠無法推論出這樣的訊息。 機器的預測式學習,是一個必須但是尚未被開發的功能,可以讓人工智慧像是小孩一樣,不需人類指導就能學習。 但是教軟體理解常識不只是一個技術性問題,這是基本的科學與數學的挑戰,需要數十年時間來解決。 在那之前,我們的機器無法稱為真正的智慧。

Predictive learning, also called unsupervised learning, is the principal mode by which animals and humans come to understand the world. Take the sentence “John picks up his phone and leaves the room.” Experience tells you that the phone is probably a mobile model and that John made his exit through a door. A machine, lacking a good representation of the world and its constraints, could never have inferred that information. Predictive learning in machines—an essential but still undeveloped feature—will allow AI to learn without human supervision, as children do. But teaching common sense to software is more than just a technical question—it’s a fundamental scientific and mathematical challenge that could take decades to solve. And until then, our machines can never be truly intelligent. —Yann LeCun

What’s Next for Artificial Intelligence

特地在feedly翻新文章來翻譯XD
Slack: @jacobchen

@maoyang
Copy link
Contributor Author

maoyang commented Jun 14, 2016

@tsengeagle @cosecantTW 邀請你們進入meet up channel了

@vneverz
Copy link

vneverz commented Jun 14, 2016

MVC stands for Model View Controller as you may already know. That makes 3 types of concerns, I know this sounds a bit esoteric but I have faith you’ll get it by reading on. Just to make things simpler, just imagine you have an application and in that application you have at least those 3 folders : models, views and controllers. Those folders contain specific files (no shit Sherlock). Now, those files are classified that way for a good reason: they have to carry on different tasks.

MVC代表你已知的模型、檢視、控制器。這涉及到三種特性,我知道這有點神秘,但我有信心你讀下去就會瞭解。簡單來說,你有個應用程式而在其中至少有三個資料夾;檢視資料夾,模型資料夾和控制器資料夾,每個資料夾包含特別的檔案(廢話)。現在,這些檔案被分門別類是有原因的:它們必須繼續不同的任務。

出處http://requiremind.com/a-most-simple-php-mvc-beginners-tutorial/
slack: @doranwu 感謝~

@justimchung
Copy link

Android Studio is the official tool for Android development these days. Being developed at the top of project IntelliJ IDEA, takes into advantage (almost in its entirety) features of edition, debugging, analysis, refactor among many other categories for developing in an effective way.

近日來,Android Studio 已經成為Android開發的官方工具了。做為一個建立在 IntelliJ IDEA 的專案,Android Studio 極盡所能地利用了 IntelliJ IDEA 本身的優勢,無論在編輯程式,除錯,分析,重構,以及其它軟體開發的部分,幫助工程師以有效率的方式來開發應用程式。

http://saulmm.github.io/the-powerful-android-studio 的第一段

slack: @justim

@maoyang
Copy link
Contributor Author

maoyang commented Jun 14, 2016

@vneverz @justimchung 已經邀請你們進入channel了 歡迎加入

@Esabella
Copy link

The last mile refers to the final stage of the development process that takes place after the software meet all its functional requirements but before being deployed into production. It involves several activities to verify whether the software that will be delivered is stable or not, such as: integration testing, system testing, performance testing, security testing, user acceptance testing(UST), usability testing, smoke testing, data migration, etc.
出處: DevOps in Practices 第一章, 1.1 https://pragprog.com/book/d-devops/devops-in-practice

最後一哩所指的是開發程序的最後階段, 此時軟體已經符合所有功能需求只差佈署營運. 這階段要做一些事來確認將出貨的軟體是否穩定, 這些事務如: 整合測試, 系統測試, 效能測試, 安全測試, 使用者接受度測試(UST), 可用性測試, 冒煙測試, 資料移轉, 等.

@JuggernautLiu
Copy link

文章出處 : http://rgalen.com/agile-training-news/2015/12/9/agile-estimation-a-general-primer

As an agile coach, it seems one of the areas that teams struggle with the most is in estimation. And by estimation I’m implying some of the following:

  • When do you “task out” the story? Who provides estimates for the tasks? And in what units?
  • How do you breakdown, estimate, and re-estimate user stories? When are you “done” estimating them?
  • Story points are relative and high level – should we convert them to hours or time?
  • At scale, let’s say 10-20 teams, the estimates are interconnected across some teams. How do we handle dependencies and integration?

身為一個敏捷教練 估算似乎是讓團隊最感到費力的其中一個項目
所以針對估算 我很懷疑下面這些問題是怎麼處理的 (是這樣翻嗎?)

  • 何時完成這個Story的Task ? 誰估算這個Task? 估算的單位是什麼?
  • 你如何估算所有的User Story? 如何拆解Story並重新估算它? 何時結束估算的循環?
  • Story Point 是個相對且概要的估算單位 我們需要轉換Story Point 成實際的時間嗎?
  • 當團隊的規模很大時, 或許是10~20個團隊, 這些團隊間的估算是互相有關聯的 , 我們要怎麼整合團隊工作項目之間的相依關係呢?

myslack id : @juggernaut

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants