• 开源镜像
  • 开源沙龙
  • 媛宝
  • 猿帅
  • 注册
  • 登录
  • 息壤开源生活方式平台
  • 加入我们

开源日报

  • 开源日报第456期:《小猿做题 mathAI》

    14 6 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《小猿做题 mathAI》
    今日推荐英文原文:《The Problem of Estimating》

    今日推荐开源项目:《小猿做题 mathAI》传送门:GitHub链接
    推荐理由:以前做题不会也想不出还没有答案的时候,小猿搜题这样的搜索 app 兴许就能成为一线生机。而这个项目虽然暂时并不能帮你解决太复杂的问题,但是如果你写一堆加减乘除的算式给它的话,它能通过图像识别看懂之后给你个答案出来——当然,不是搜出来而是自己做出来的。尽管在现在的版本中它只能做做简单四则运算,但是这只是个基础而已,它还有很大的发展空间。
    今日推荐英文原文:《The Problem of Estimating》作者:Robert Field
    原文链接:https://medium.com/@snarfoid/the-problem-of-estimating-fcb9e4527950
    推荐理由:估算越多就越容易出现不确定因素,这在哪里都是一样的

    The Problem of Estimating

    Estimating problems is commonplace, especially in the world of high tech, and is a valid exercise. What could be more natural than wanting to know how long something will take to finish? How long till my table is ready? When will my pizza arrive? When are you going to check in? All estimates. Every answer satisfies that basic need to know, even though every one is a guess. Maybe a very educated guess, based on data or heuristics, but still a guess.

    When the problem at hand is simple, a guess is fine. If my table took fifteen minutes instead of the alleged ten, I sucked it up. I didn’t starve. No one went to the hospital. It was inconsequential. An estimate then, for an inconsequential problem, is perfectly fine. There are no real repercussions. Now guess what? Not all problems are like this. If your Mom has stroke, it matters if you get her to hospital within the hour. That is not a problem you want to under estimate.

    Let’s take the stakes up a notch to my high tech world. I got tasked with estimating the scope of a very large project for a large client. The client wanted to know, quite naturally, how much effort the project was. In other words, how much was it going to cost them? Once you start talking real money, estimates do have consequences. Everyone loves coming in under budget, but over budget is way, way different. Things get really uncomfortable in that case.

    So I pondered over the problem set, got the basic holes ironed out. resolved all the dependency issues, and determined how to split up the work among our teams. Like I said, it was a large project, and so my estimates were large. With something so big, I felt a real need to build in some flexible time to deal with unforeseen issues and the inevitable bugs that would also arise. I’ve been through this before, and nothing really ever goes just the way you plan it. The bigger it is, the less likely it is to go well.

    My boss nearly coughed up his liver when I showed him the numbers. He was adamant that there was no way we could deliver these numbers to the client. It was just unacceptable. So we bargained. This shouldn’t take so long, that we can skip testing, and the other thing can be done in parallel. If everything went super smoothly, maybe, just maybe, it would work. So the numbers came down, not where I wanted, and not where my boss wanted either. But the new numbers were deemed acceptable for presentation.

    Work began. Code got checked in. Testing started. Hooray, the project was released. Except, not hooray. Horror. There were critical bugs right from the start. Every time we would solve one, two more came in. We were drowning, and the client, not surprisingly, became, shall we say, unhappy. They were quite rightly pissed, as they should have been.

    My take away lessons from this unfortunate episode were two-fold. First, going in with my original numbers would have made the client unhappy from the start. Assuming they wanted to proceed from there, we would have in theory delivered a quality product, resulting in a happy customer. Instead, we chose a short-term trick to get the client to accept, then both made the client unhappy and made ourselves look bad, damaging our relationship. The lesson is that risk is very real, and the consequences of missing an estimate can be high.

    Second, any project comes with ups and downs. You should know in advance what the real goals are. You have likely heard the of the project management triangle. Pick two: cheap, fast, good. In my example above, we clearly, though perhaps unconsciously, picked cheap and fast, unknowingly sacrificing quality. Knowing our client, our guiding principles should have been cheap and good, thus ignoring our time to completion, or, dare I say, going with my original numbers. But the client had an alleged deadline, things got negotiated around, and we wound up in a mess.

    So as wonderful as estimates are, sometimes things take as long as they take. You can’t plan for everything single thing, but you can plan for how you want to deal with the problem and where your biggest risk is.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第455期:《无中生有 wheels》

    13 6 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《无中生有 wheels》
    今日推荐英文原文:《But, What Exactly Is AI?》

    今日推荐开源项目:《无中生有 wheels》传送门:GitHub链接
    推荐理由:学透一个东西有不少途径,其中一个就是把它制造出来。这个项目就是作者自己做的轮子——不使用其他的依赖而是自己空手制作。有的时候我们不可避免的会在工作时使用一些简单易用的轮子来组装自己的车,这会让我们的工作快上不少,但是如果想学透细节,可以试着挑战不依靠其他东西而只使用基础语言等重新实现它——有时这甚至比原作者的工作更难,这会让你学到很多实践才能了解到的知识。
    今日推荐英文原文:《But, What Exactly Is AI?》作者:Rich Folsom
    原文链接:https://towardsdatascience.com/but-what-exactly-is-ai-59454770d39b
    推荐理由:AI 究竟是什么——用简单点的方法去介绍的话

    But, What Exactly Is AI?

    For years, people viewed computers as machines which can perform mathematical operations at a much quicker rate than humans. They were initially viewed as computational machines like glorified calculators. Early scientists felt that computers could never simulate the human brain. Then, scientists, researchers and (most importantly probably) science fiction authors started asking “or could it?” The biggest obstacle to solving this probem came down to one major issue: the human mind can do things that scientists couldn’t understand, much less approximate. For example, how would we write algorithms for these tasks:
    • A song comes on the radio, most listeners of music can quickly identify the genre, maybe the artist, and probably the song.
    • An art critic sees a painting he’s never seen before, yet he could most likely identify the era, the medium, and probably the artist.
    • A baby can recognize her mom’s face at a very early age.
    The simple answer is that you can’t write algorithms for these. Algorithms use mathematics. Humans that accomplish these tasks couldn’t explain mathematically how they drew these conclusions. They were able to achieve these results because they learned to do these things over time. Artificial Intelligence and Machine Learning were designed to simulate human learning on a computer.

    The terms Artificial Intelligence(AI) and Machine Learning(ML) have been used since the 1950s. At that time, it was viewed as a futuristic, theoretical part of computer science. Now, due to increases in computing capacity and extensive research into Algorithms, AI is now a viable reality. So much so, that many products we use every day have some variation AI built into them (Siri, Alexa, Snapchat facial filters, background noise filtration for phones/headphones, etc…). But what do these terms mean?

    Simply put, AI means to program a machine to behave like a human. In the beginning, researchers developed algorithms to try to approximate human intuition. A way to view this code would be as a huge if/else statement to determine the answer. For example, here’s some pseudocode for a chatbot from this era:
    if(input.contains('hello'))
      response='how are you'
    else if (input.contains('problem'))
      response = 'how can we help with your problem?')
    ...
    print(response)
    
    As you can imagine, this turned out to be an incredibly inefficient approach due to the complexity of the human mind. The rules are very rigid and are most likely to become obsolete as circumstances change over time. That’s where ML came in. The idea here is that instead of trying to program a machine to act as a brain, why don’t we just feed it a bunch of data so that it can figure out the best algorithm on its own?

    ML turned out to be a groundbreaking idea. So much so that nowadays, researchers and developers use the terms AI and ML almost interchangeably. You will frequently see it referred to as AI/ML, which is what I will use for the rest of the article, however, be cautious if you run into a Ph.D./Data Scientist type, as they will undoubtedly correct you.

    Before we go any further, we need to take into account one global truth for AI/ML. Input data is always numeric. Machines can’t listen to music, read handwritten numbers, or watch videos. Instead, these have to represented in a digital format. Take this handwritten number, for example:

    https://colah.github.io/posts/2014-10-Visualizing-MNIST/

    On the left is what the image looks like when represented as a picture. On the right is how it actually viewed internally by the computer. The numbers range between zero (white) and one (black). The key takeaway here is that anything that can be represented numerically can be used for AI/ML, and pretty much anything can be represented numerically.

    The process of AI/ML is to create a model, train it, test it, then infer results with new data. There are three main types of learning in AI/ML. They are Supervised Learning, Unsupervised Learning, and Reinforcement Learning. Let’s look at these in detail.

    Supervised Learning

    In this case, we have input data and know what the correct “answer” is. A simple way to visualize the input data is a grid of rows and columns. At least one of the columns is the “label,” this is the value we’re trying to predict. The rest of the columns are the “features,” which are the values we use to make our prediction. The process is to keep feeding our model the features. For each row of input data, our model will take the features and generate a prediction. After each round (“epoch”), the model will compare it’s predictions to the label and determine the accuracy. It will then go back and update its parameters to try to generate a more accurate prediction for the next epoch. Within supervised learning, there are numerous types of models and applications (predictive analytics, image recognition, speech recognition, time series forecasting, etc…)

    Unsupervised Learning

    In this case, we don’t have any labels, so the best thing we can do is to try to find similar objects and group them into clusters. Hence, Unsupervised Learning is frequently referred to as “clustering.” At first, this may not seem very useful, but it turns out to be helpful in areas such as:
    • Customer Segmentation — what types of customers are buying our products and how can we customize our marketing to each segment
    • Fraud Detection — assuming most credit card transactions follow a similar pattern, we can identify transactions that don’t follow that pattern and investigate those for fraud.
    • Medical Diagnosis — Different patients may fall into different clusters based on disease history, lifestyle, medical readings, etc. If a patient falls out of these clusters, we could investigate further for potential health issues.

    Reinforcement Learning

    Here, there’s no “right” answer. What we’re trying to do is train a model so that it can react in a way that will produce the best result in the end. Reinforcement Learning is frequently used in video games. For example, we might want to train a computerized Pong opponent. The opponent will learn by continuing to play pong and get positive reinforcement for things like scoring and winning games, and negative reinforcement for things like giving up points and losing games. A much more meaningful use of Reinforcement Learning is in the area of autonomous vehicles. We could train a simulator to drive around city streets and penalize it when it does something wrong (crash, run stop signs, etc…) and reward it for positive results (arriving at our destination).

    Conclusion

    If you’re new to AI/ML, hopefully, this article has helped you gain a basic understanding of the terminology and science behind it. If you’re an expert in these areas, maybe this article would be useful in explaining it to potential customers who have no experience with it.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第454期:《高质量文档 The-Documentation-Compendium》

    12 6 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《高质量文档 The-Documentation-Compendium》
    今日推荐英文原文:《Get Comfortable Not Knowing》

    今日推荐开源项目:《高质量文档 The-Documentation-Compendium》传送门:GitHub链接
    推荐理由:编写文档的小技巧。大部分人看到一个项目时最开始看到的就是它的 README 和文档了,而这个项目就提供了一些 README 的模板以及关于编写程序文档的技巧。写文档不光是给别人看的,也是让以后你重新回来时看的,一些小玩意可以快速的扫一遍代码来弄懂你干了啥还没干啥,但是一旦这玩意的规模大起来,光是这一步就会浪费你很多时间,而一个简单的文档就能解决这个问题。
    今日推荐英文原文:《Get Comfortable Not Knowing》作者:Sean Watters Sean Watters
    原文链接:https://medium.com/better-programming/get-comfortable-not-knowing-745aa7c6d4c5
    推荐理由:不需要为未知感到担心,最起码还有学习和求助的机会

    Get Comfortable Not Knowing

    I wrote an article a couple of weeks ago about prioritization and understanding goals in a broader context. A big part of remaining goal-oriented, while still navigating a complex problem or project, is being able to learn quickly and becoming comfortable with not knowing.

    Get Comfortable Not Knowing

    At the start of any project, anticipating there will be problems you don’t yet know how to solve is incredibly helpful. This anticipation allows you to approach all tasks — even the ones you’re familiar with — flexibly and with less discouragement as you progress.

    Often, relearning a familiar task reveals quicker or more efficient solutions to problems you didn’t anticipate. Better implementation of a familiar component will often compensate for deficiencies elsewhere.

    There are often situations where partners and team members come from different backgrounds with diversity of skill and experience. I recently worked on a prototype for a mobile app with a team member. We both had some shared experience working with rails, but the majority of his experience had more to do with front end development. Given that I was more familiar with relational database structure and back end, clear communication about our respective understanding was important. We had a short time frame to build out something workable. As we worked on building the MVP, obviously, all or most components of the project required enough understanding of the other’s work to progress and create something usable.

    When workload is distributed to larger groups, good communication between team members and teams is super important. Willingness to admit when certain implementation wasn’t immediately understood was vital for us to move quickly through roadblocks. Without honest communication, much time would have been spent spinning in place, preventing progress toward the overall goal. Asking questions allows you to avoid needlessly wasted energy.

    The faster you are willing to say, “I don’t know”, the faster your team can start on a path toward a solution. Being willing to say, “I don’t know” quickly is crucial to project success, especially in a tight window.

    Be Patient with Yourself and Your Team Members

    When you hit a roadblock, the “right” place to start often feels unknowable until long after you understand what you were fixing in the first place. Setting a growth target is important. However, allow for the possibility that you will spend time distracted by something that appears to be necessary and later is found not to have been. Plenty of things learned will be found later to have been irrelevant to solving the initial problem.

    A helpful guardrail for navigating a new landscape and avoiding the “will learning this matter, later?” questions, is seeking out mentors and peers who have struggled through similar problems before — prioritize working with those assets.

    Be patient with yourself as you navigate through new material but more importantly, foster a culture that is patient for all team members. It is especially important to be patient as team members navigate unfamiliar territory or material you already have an established understanding of. Be the asset to your teammates that you would look for in a mentor. Avoid interjecting “well actually’s.” Instead, set out to be someone who makes it safe to ask questions. “Well actually” sets the wrong precedent and makes it unsafe to ask questions, even if your intent is to be helpful.

    The Difference Between Knowing Enough and the Bare Minimum

    As you’re tackling a new concept, it’s important to emphasize understating enough. Enough and the bare minimum are not the same.

    The bare minimum is about foregoing necessary understanding of a topic to implement short-term solutions with the false appearance of completion. Enough is about building a solid base of understanding with the intent of furthering growth in the future. It’s important to spend a non-trivial amount of time when solving the immediate problem, but without exceeding reasonable bounds.

    Full understanding is often unattainable or unnecessary. Understanding enough becomes more important when the path to deeper understanding later is dependent on ‘just getting in the door.’

    In many cases, just getting the job or getting accepted to an academic program allows you much greater opportunities for learning. There are many cases where it doesn’t make sense to ignore current priorities and go learn it all before applying. Prioritize enough in contexts where you will spend otherwise useful energy on something that can be learned trivially in a more productive context with better guidance.
    Calvin and Hobbes by Bill Watterson

    Don’t Stop Learning

    Get comfortable saying, “I don’t know” quickly. It allows for flexibility as you navigate complex problems. The belief that you can ‘arrive’ or attain complete understanding is often discouraging and limiting — rarely is full understanding attainable. As you work through things unfamiliar, allow yourself the freedom to embrace what you don’t know and pursue resources and individuals who will help you grow.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第453期:《魔幻线条 curvejs》

    11 6 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《魔幻线条 curvejs》
    今日推荐英文原文:《Why Everyone is Telling You to Read the Docs.》

    今日推荐开源项目:《魔幻线条 curvejs》传送门:GitHub链接
    推荐理由:在你的浏览器页面上利用三次贝塞尔曲线生成跳动的魔幻线条——简而言之,效果就像以前 Windows 屏保的变幻线一样。只需要提供点,颜色和随机值之类的自定义数值,而不需要考虑自己解决阴影特效,就能够自己让线条开始跳舞,自己写一个然后把浏览器全屏了假装屏保也没有什么违和感(尽管这并不会起到实质性作用)。
    今日推荐英文原文:《Why Everyone is Telling You to Read the Docs.》作者:Brandon Pampuch
    原文链接:https://medium.com/@brandonpampuch/why-everyone-is-telling-you-to-read-the-docs-8c3eb4e97f75
    推荐理由:将官方文档作为教程是个好事——尽管视频之类的比较好懂,但是做视频需要时间,而官方文档的更新永远是最快的那个

    Why Everyone is Telling You to Read the Docs.

    I have a confession to make. Until recently I rarely read the docs. I believed they were not for me. I couldn’t stay focused on written materials for more than a few minutes, but I could remember every lecture or conversation about coding with clarity.

    When we begin coding there is a natural tendency to lean towards video instruction. It is easy to follow and the results are immediate. Therefore we sometimes stick to video tutorials, courses, and lectures exclusively later in our learning journey. We begin to believe they are more efficient or “the way I learn”.

    As you become more comfortable with coding, and as you begin to see the full stack from the trees, the way you learn changes. You know how apps work and therefore you are not afraid to break them. You start to consume information more quickly and need less instruction.

    At that point, there are huge payoffs for beginning to use source docs.
    1. Docs are faster. In the docs you will often be looking for the information you don’t know, not a complete tutorial front to back.
    2. The information will be up to date. You will never have to wonder if a newer version has a different syntax or expanded functionality.
    3. You can decide how to use a certain language, library or framework instead of having someone tell you how they would use it.
    As a disclaimer, I would like to say that I use neither video nor documentation exclusively. In fact, I often use them in conjunction. I will watch something online briefly (depending on the tech) and then begin playing with it. I download the package, jump into the code, open up the docs, and let the good times roll.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
←上一页
1 … 145 146 147 148 149 … 262
下一页→

Proudly powered by WordPress