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

开源日报

  • 开源日报第874期:《写字 hanzi-writer》

    24 8 月, 2020
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《写字 hanzi-writer》
    今日推荐英文原文:《Testing is not a first class citizen.》

    今日推荐开源项目:《写字 hanzi-writer》传送门:项目链接
    推荐理由:这个项目是一个关于汉字笔画顺序的 JS 库——包括展示正确的书写动画以及对用户的输入笔画进行识别来确认书写顺序是否有误两个方面。很容易想到它可以作为汉字书写教学网站的核心来使用,不过没准也可以用于一些特定主题网站的验证码上,顺便还能防止敲键盘太多忘记如何写字的副作用。
    今日推荐英文原文:《Testing is not a first class citizen.》作者:James O’Toole
    原文链接:https://medium.com/nomoss/testing-is-not-a-first-class-citizen-90088f0e4245
    推荐理由:尽管测试已经成为了开发的一环,但是大部分语言依然没有太多面向测试的部分

    Testing is not a first class citizen.

    Here’s a fun list; programming languages which don’t have unit testing built into their standard compiler/runtime tool-sets or standard libraries.
    • Java/JDK (It includes 33 other binaries and tools however. ?)
    • PHP (PHP Unit, like JUnit is a framework and does not come with the language)
    • Node/JS — Nope. Most active language and testing is an after thought. —
    • C++ (No standard or standard library tooling)
    Well, then who the heck does?
    • Python has a in its standard library unittest API, though it’s a bit limited.
    • Golang has go test, built in to the compiler tool-chain that’s quite nice. Has no assert statement though which annoys me bit
    • Rust has various macros to assist in testing and it is built into cargo
    • Ruby has a Test standard library package.

    So What?

    1.Its not in the design of the language, it’s not going to be in the ethos of your developers, your community and your projects. If it’s an afterthought to the language and it’s creators, why should we expect it to be different for the frameworks that drive the application development. Why would we expect libraries to give it the same duty of care in considering how their implementations will fit into peoples testing framework, particularly if you can’t judge which of their community tool-sets they’ll be using. This is where not even having things like assert in your language and basic constructs for people to test the code that they write will lead to a trickle down effect on everything that touches it.

    2.The stopgap solutions have deficiencies and approaches which are come up by community standards, this trickles into the frameworks and leads people to steer away from testing their code. NodeJS not having a testing binary means we rely on fragile community tools. JUnit might be a defecto standard, but it’s still a dependency, not a first class citizen. This means every project will include extra tools for their specific needs, will bring in their own specific approaches to solve mocks and dependency injection. Learn one framework and you’ll need to learn a different set of testing tools because the standard is not defined.

    3.Affordances in design intent create better results for the people that have to use them. Put a shoe rack at the front of your house and people will leave their shoes there. I’m talking about creating simple affordances to make it simple to do the right thing. Rust built it well into its language, and it begot rspec which became the golden standard for BDD tests. My favourite thing about Golang is the SRCFILE_test.go pattern which encourages you to write tests along side your source files. Not hidden in away in another folder but first class to your own code base. If your tests files are treated as just as essential to your source code then it will be treated as such. Make it easy and people will do it, and consistently. Your code should be as easy to create to the standards of the Standard Library, Go is the only language that’s made that possible in my experience.

    “But we can just do what the right anyway”. Yes, we can. Of course, I believe that strongly teams and individuals can create, discuss and adapt standards to do things better. However, every month programming languages continue to keep getting more features, more things to optimise and increase better ways of doing things, but they’re ignoring blatant gaps. Why is there still no official testing binary in NodeJS is beyond me, and projects would have gone in much better directions if there was. Instead people have relied on whatever the testing tool is flavour of the month and ready to become apart of your growing NPM dependency debt.

    There is endless debate and great reading on different ways in which testing approaches can benefit how you write your code and tests; but I wanted to express my frustration. Good design in tools can create better results, and I feel like with every passing year of my dev life I love Golang more and more the choices the team made in its creation.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第873期:《Chinese-programmer-wrong-pronunciation》

    23 8 月, 2020
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《Chinese-programmer-wrong-pronunciation》
    今日推荐英文原文:《Will We Ever Touch The Stars?》

    今日推荐开源项目:《Chinese-programmer-wrong-pronunciation》传送门:项目链接
    推荐理由:该项目致力于纠正程序员常见的的错误发音,以避免可能的交流障碍和短暂的尴尬。
    今日推荐英文原文:《Will We Ever Touch The Stars?》作者:Alastair Isaacs
    原文链接:https://medium.com/predict/will-we-ever-touch-the-stars-d1af1035ec8b
    推荐理由:半人马座α星可能是最受地球人偏爱的星系,毕竟它距离我们仅有4.24光年。本文从经典的火箭-燃料的矛盾出发,介绍了一种可能到达的方式:利用太阳光的动量驱动探测器。

    Will We Ever Touch The Stars?

    Space is big, really big. Even the closest stars are unimaginably far away. Alpha Centauri — the Sun’s nearest neighbour — is so distant that light itself takes more than four years to cover the distance. And that’s just the closest one— most of the stars you see in the night sky are hundreds of times further away.

    Could we ever cross these vast distances? Could a man, or woman, ever walk on a world around another Sun? To do so we’ll either need to spend centuries or even millennia en route, or find a way to go really, really fast.

    To date, humans have only travelled to our closest cosmic neighbour, the Moon. That journey, a paltry 240,000 miles (380,000 km), took the Apollo astronauts just over three days, averaging three thousand miles per hour. At that speed, assuming our plucky astronauts can tolerate the cramped living conditions, it would take almost a million years to reach Alpha Centauri.¹

    (The Saturn V, the most powerful rocket ever built, lifts off from the Kennedy Space Center. Image credit: NASA.)
    The Apollo programme used the biggest rocket ever constructed, the Saturn V, burning more than 40,000 pounds of fuel every second. But, even with all that power, we are still nowhere near reaching the stars. More than fifty years have now passed since the Moon landings. Surely modern technology can do better?

    Indeed it can, but not by much. Since the 1970s humanity has launched five probes to the outer solar system. Having completed their primary missions, those five spacecraft are now heading for interstellar space. The fastest, Voyager I, travels ten miles every second — a blistering 38,000mph. If Voyager I were heading directly towards Alpha Centauri, it could reach the star system in slightly less than 80,000 years².

    It is an improvement over Apollo, but a journey time measured in millennia isn’t much good if we want to get something useful from the trip. To reach the stars in a shorter time we’ll need a way of travelling at a decent fraction of the speed of light — somewhere between a tenth and a fifth. At that speed a hypothetical probe could get to the closest stars in forty to eighty years. Certainly not a short trip, but short enough to complete in a single lifetime.

    Can it be done? Scientists and engineers think it probably can, but to do so will require rethinking our entire approach to space exploration. We’ll need new and exotic technologies, and propulsion systems of immense power. Most of all, we’ll need a lot of money.

    Until now, most space flights have followed the same approach. Build a big rocket, stick a probe or capsule on top, and light the fuse. Rockets work by burning chemical fuels — similar to the way an internal combustion engine powers a car. This delivers a powerful jolt of momentum to the spacecraft, directing it towards a planet or moon. Once underway, small course corrections can be made with thrusters using various types of gas.

    This approach works reasonably well for nearby objects, but, as we already saw, it is far too slow to cross the vast interstellar distances. Rocket engineers have started experimenting and dreaming of alternative fuel sources — from electric propulsion, to nuclear powered rockets, and even antimatter fueled engines.

    All these techniques suffer from one big problem — they need the rocket to carry a lot of fuel, and that adds a lot of weight. The more weight you add, the more fuel you need to propel yourself to high speeds. Rocket designers quickly get stuck in a vicious loop, adding more and more fuel to gain slightly more speed.

    To go really, really fast, we need to leave the fuel behind. Luckily, engineers have come up with one approach to space travel that does just that. The idea is to harness the power of sunlight. That might seem fantastical. How can light move a spacecraft at all, let alone accelerate it to hundreds of thousands of miles per hour? And yet, since the Victorian Era, scientists have known that light can indeed move objects, if only very slowly.

    Those Victorian physicists discovered that light, although massless, carries a small amount of momentum. Every time a photon of light strikes a surface and bounces off, it exerts a tiny force on the surface. Place a mirror in space then, and the cumulative pressure of the Sun’s light will slowly push it away from the star.

    The effect is tiny, but is significant enough that mission designers have to take it into account when planning orbits for spacecraft. If they didn’t, reaching the planets would be impossible. Without accounting for sunlight, a typical spacecraft heading to Mars would be more than 15,000 miles off course by the time it arrived.

    (An artists concept of NanoSail-D, an experimental solar sail launched in 2011. Image credit: NASA.)
    To reach the stars in a short enough time, we’ll need a way to magnify the power of sunlight. The most obvious way to do that is to use a bigger mirror — known as a solar sail. A spacecraft powered by a solar sail needs no fuel, reducing its weight, and experiences a small but steady acceleration away from the Sun. What’s more, that acceleration will gradually reverse as the probe nears its destination star, helping to slow the probe for arrival.

    How quickly can a solar sail reach Alpha Centauri? Using sunlight alone, and a large sail the size of several football fields, some scientists have estimated it would take a few thousand years. That’s a big improvement on current methods, but still not within a human lifespan.

    To get faster, scientists have suggested using focused lasers to power the solar sail. A powerful laser, aimed at the sail from Earth, would increase the acceleration many times over, cutting the journey time to no more than a century. Add in miniaturisation — allowing ever smaller and lighter probes, and recent studies think we could reach Alpha Centauri in a few decades.

    These ideas might seem farfetched, but some at least are taking them seriously. The most ambitious attempt is Project Starshot, funded by the Russian billionaire Yuri Milner. He is pouring money into solar sail, laser and miniaturisation research. His goal is to send probes to Alpha Centauri and other nearby stars within the next few decades.

    To reach Alpha Centauri, Project Starshot has suggested constructing a fleet of tiny spacecraft, each powered by a solar sail. An array of powerful Earth-based lasers, each using the power consumption of a small city, will accelerate the probes to a fifth of the speed of light. Such speeds carry enormous dangers — even a collision with a grain of dust would be devastating — but Project Starshot think enough would survive to reach our neighbour.

    (Alpha Centauri, our neighbouring star system, is composed of three orbiting stars. Two are visible in this image. Recent discoveries indicate that at least two planets are present in the star system. Image credit: Digitized Sky Survey 2, Davide De Martin/Mahdi Zamani)
    Although it has the financial backing of a billionaire, Project Starshot is facing enormous odds. The most formidable challenges lie in the lasers. Can we even construct one so powerful? How do we prevent the solar sails from melting under such intense radiation? And what happens if those lasers fall into the wrong hands? Such a device would not just serve as a propulsion device; it could also act as a terrible weapon.

    But even if Yuri Milner and Project Starshot fail to reach the stars, their ideas could bring benefits closer to home. Right now reaching the outer planets takes decades and costs billions of dollars. Breakthroughs in solar sail technology could reduce that travel time significantly, and trends in miniaturisation offer to make space exploration far cheaper.

    In the end, we may not be ready for interstellar travel just yet. But surely, if we keep dreaming of the stars, it won’t be long until we reach out and touch them.

    ¹A million years is probably wrong. The stars are not stationary, they move around. Over a few tens of thousands of years the Sun and Alpha Centauri will drift apart. By the time a million years has passed, our intrepid astronauts will likely be lost in deep space, desperately hoping to pass close by an hospitable star.

    ²Voyager I, and the other probes heading into deep space, did not achieve their high speeds from rockets alone. They also took advantage of gravitational interactions with planets. In each interaction the planet boosts the speed of the spacecraft. In exchange, the planet slows ever so slightly.


    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第872期:《googletest》

    22 8 月, 2020
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《googletest》
    今日推荐英文原文:《TikTok removed more than 380,000 US videos this year for hate speech》

    今日推荐开源项目:《googletest》传送门:项目链接
    推荐理由:在一些项目中, 有些测试问题无法通过集成测试解决, 需要进行单元测试. 为此, 谷歌开发出名为googletest的C++测试框架, 它可以输出尽可能详细的错误信息, 提高了测试效率, 并且支持3平台.
    今日推荐英文原文:《TikTok removed more than 380,000 US videos this year for hate speech》作者:Queenie Wong
    原文链接:https://www.cnet.com/news/tiktok-removed-more-than-380000-us-videos-this-year-for-hate-speech/
    推荐理由:抖音在美国的生死存亡被全世界的人们所关注, 于此同时, 美国的种族歧视问题也没有完全解决. 白人在抖音平台上散布了大量的种族歧视视频被抖音以删除的方式所处理.

    TikTok removed more than 380,000 US videos this year for hate speech

    TikTok, known for short videos of people lip-syncing and dancing to their favorite songs, is grappling with a problem familiar to other social networks: hate speech.

    On Thursday, TikTok said it removed more than 380,000 videos in the US this year for violating its rules against hate speech. The company also banned more than 1,300 accounts for hateful content or behavior, and took down more than 64,000 hateful comments.

    TikTok defines hate speech as “content that intends to or does attack, threaten, incite violence against, or dehumanize an individual or group of individuals on the basis of protected attributes like race, religion, gender, gender identity, national origin, and more.”

    The short-form video app, which is used by 100 million Americans, is filled with content that promotes white supremacist groups and antisemitism, according to a report released in August by the Anti-Defamation League. Civil rights activists have urged social networks, including Facebook, to do more to pull down hateful content on their sites.

    TikTok has other problems to worry about outside of hate speech. It’s been targeted by the Trump administration because the video app is owned by Chinese tech company ByteDance. The president has signed two executive orders that impact TikTok’s future. One order would bar any US transactions with ByteDance and its subsidiaries, which means that TikTok would effectively be banned in this country if it’s not sold to another company by Sept. 20. Another executive order, signed last week, ordered ByteDance to sell TikTok’s US operations within 90 days. Both orders cite national security concerns about TikTok. The company has said that it wouldn’t turn over US user data to the Chinese government even if it were asked to do so.

    Microsoft, Oracle and Twitter have been in talks with ByteDance about purchasing TikTok’s US operations. But acquiring a social media company also means they would have to deal with content moderation issues. In an interview with Wired, Microsoft co-founder Bill Gates has described a potential deal with TikTok as a “poisoned chalice,” adding that “being big in the social media business is no simple game.”

    Eric Han, who oversees safety at TikTok in the US, said in a blog post that the company wants to improve its hate speech policies and how it tackles this problem. He outlined five ways TikTok is trying to address hate speech. The company consults with experts to make any changes to its hate speech policies and takes action against this type of content by banning accounts or not including offensive content in search results. When users search for “heil Hitler” on the app, for example, the company wouldn’t show these results or redirects them to its rules against hate speech. The company also trains content moderators to understand different cultures. Some groups have reclaimed ethnic slurs to fight back against people who try to oppress them with derogatory terms. TikTok said it’s trying to increase transparency about content moderation and invest in tackling hate speech.

    “We recognize the perhaps insurmountable challenge to completely eliminate hate on TikTok — but that won’t stop us from trying,” Han said.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第871期:《虚拟键盘 Keyboard》

    21 8 月, 2020
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《虚拟键盘 Keyboard》
    今日推荐英文原文:《You Should Write Bad Code More Often》

    今日推荐开源项目:《虚拟键盘 Keyboard》传送门:项目链接
    推荐理由:这个项目可以在浏览器页面中根据需要添加虚拟小键盘,而且根据不同的需求还提供了不同的色彩主题(诸如黑暗模式等)与不同的扩展插件(包括支持通过物理键盘直接输入与自动补全等),尽管对于有键盘的台式机与笔记本电脑来说可能有些多此一举,但是对于没有键盘的设备,或者需要输入特殊字符的场景,这个项目依然有用武之地。
    今日推荐英文原文:《You Should Write Bad Code More Often》作者:Ygor Rebouças Serpa
    原文链接:https://medium.com/better-programming/you-should-write-bad-code-more-often-388c6f1ba5a
    推荐理由:编程语言中有些概念并非生来就遭受非议,而是在不断尝试中发现错误的使用方式会使其反而成为绊脚石,这种尝试能让开发者更好的了解如何正确使用这把双刃剑

    You Should Write Bad Code More Often

    And how to spot bad coding advice

    Every week a “don’t do this” article is posted somewhere. Don’t use inheritance, never write a singleton, scrum is dead. But are we really supposed to abandon it all? Is an if-statement really that bad a thing? How can we tell what advice is worth listening to?

    There isn’t a perfect programming language, nor is there a right way to code. There are guidelines (and known pitfalls). Browsing through programming advice on the internet today is terrifying — everyone is telling you to stop doing something. Soon we’ll be out of commands to use. Everything is a source of bugs.

    Consider this analogy: You don’t send a truck down a wooden bridge and expect it to reach the other side. That doesn’t means wooden bridges are dead nor that you should stop using trucks.

    Programming languages give us tools. It’s up to us to know when, why, and how to use them. Don’t throw your hammer away because you hit your finger — improve your aim.

    How to Spot Bad Advice?

    Good advice has three parts. First, the information itself, second, its when, and third its when not to. Bad advice often lacks the second and third part — it’s presented as something that always works.

    A common theme is to “avoid inheritance at all costs.” If left without the when or when not to, you might end up blindly following this and lose one of OO’s most essential tools. Instead, consider the following: “inheritance is a great tool. However, deep hierarchies are often harmful.” This time around its clear that the problem is depth. This explanation is far more precise and provides a direct insight into the matter, telling us that shallow hierarchies are fine.

    Another thing to keep an eye on is language. Many writers are trained to “write boldly and never ask forgiveness.” This kind of tone is known to do well on the internet and particularly Medium. The problem is that boldness for the sake of boldness is damaging. People forget to add that their advice is not for every case. To avoid sounding weak, they ignore the when not to.

    Good advice is friendly, not intimidating. Recall all the genuine help you have had over the years. Has any of it been given angrily?

    Rules of Thumb

    When it comes to coding, in particular, two rules of thumb apply:

    1. Languages are expensive to create and maintain. If a feature keeps being added to new languages, it still has an important role to play.

    That’s why the global scope is still a thing, as is inheritance and the if-statement. Any article stating that those should be avoided entirely is missing a pretty important aspect of these features.

    A good example is typing. The sensual type-less world of Python and JavaScript allured many developers to their embrace, who would later regret writing ten thousand lines in such unstructured languages. None of that existed on the old fashioned world of Java and C# (which doesn’t mean they were any paradise either).

    It is no wonder TypeScript is a thing. Typing has returned as loosely typed languages — you type just enough, the compiler fills the rest. This idea was so successful that it entered the C# and C++ worlds, through the var and auto keywords, respectively. Even Python has typing features by now.

    In the opposite direction, the second rule of thumb is:

    2. Modern languages have taken down all the really nasty stuff by design

    That’s why we don’t see macros anymore or goto statements or explicit memory management. Java had quite some bad press for its GC back in the day, but GCs have outgrown the JVM to pretty much all modern languages.

    A recent removal is the null pointer exception. Modern languages like Kotlin and Swift enforce null checking by design. C# 8 is following a similar route. Raw threading and async callbacks have also had their share of problems. Now, we code asynchronous tasks with handy async/await constructs.

    All this brings us to the following:

    If you want to be a better coder, learn about programming language history

    While most languages were born out of individuals with an excellent sense of tooling, their developments are led by committees. Whenever new features are added, there is an entire body of work dedicated to discussing their relevance and worth to the community, as well as to perfect its design. The same goes for changing and removing features. Python 3 brought many breaking changes that were hard to ignore, but it all paid off.

    Write Bad Code More Often

    All we use is the product of decades of innovations and failed designs.

    You can only truly grasp the beauty of a garbage collected language if you dive on some nasty C/C++ code. Until then, all you can do is imagine how painful it was back in the day. The whole hate over singletons can only really be understood by those that got to write one and faced the many issues associated with them (such as writing tests).

    Theres a whole world between textbook samples and real-life experience. The former is no more than a hint; the latter really changes how you code.

    Most of us, back in our beginner days, coded without Git or Unit Tests. These projects tended to be buggy, and, more often than not, they would stop working at all. Without Git, you couldn’t tell what you might have accidentally changed. Without tests, things would stop working days before you bumped into them again. This experience is what motivates us to use these tools every day.

    To truly understand how to write good code, you must write bad code first.

    There a couple of ways you can force yourself to write bad code (or to see ugliness in your current snippets). It all boils down to one thing: try coding some other way. This will either show you how much better your solution is or how stupid it was (“was” because you’ll change it, right?)

    Here’s a list of things you can do in your spare time:
    1. Learn a Parent Language: Kotlin, for instance, is inspired by Scala. Swift, among other things, tries to solve Objective-C issues. C# superseded Java. Learning parent languages teach you how much of “what you have now” was not present back then (and what it solves). It will teach you to appreciate more a lot of things you might otherwise think are crap.
    2. Learn a “Successor” Language: If you are a C++ developer, you should try Rust. Java folks should give Go a go. Python users might try Julia or Nim. JavaScript guys ought to try TypeScript or maybe Dart. Unlike learning a parent language, this will show you how much of what you do now is crap and how it could be better handled.
    3. Learn LISP: This is a weird one for many. LISP has no variables. It is a fully functional programming language (that’s easier than Haskell). You don’t need to be any proficient with it, but try writing some algorithms, such as Fibonacci, quick-sort, or Huffman coding. If you take your time to do so, you will realize how variables are, many times, unnecessary.
    4. Write a Text Processor in Plain-C: Given a path to a text file, open it, remove all line breaks, and add new breaks after every period (.) character. Then, shuffle each word keeping the first and last characters unchanged. Bonus points if you process each line in parallel. This will (quickly) show you how string processing has evolved dramatically.
    5. Look for Design Patterns: Take a list of design patterns, such as this one(https://sourcemaking.com/design_patterns), and open up some project you work or worked on. Take your time to read about each pattern and try finding places that could benefit from one of such patterns. For each one you see, try picturing how much cleaner it would be if you had used it (bonus points if you refactor it). This is the best way to incorporate design patterns into your repertoire.
    These tips, in essence, are all trying to either make you code differently or take a second look at what you have already done. Either way, you’ll notice that not everything is as shiny as you might have once thought.

    Besides, I am not telling you what’s wrong or what is right, nor how to code. Instead, I invite you to…code. Code in a new language. Try doing the same thing in two different ways. Coding is the way to be a better coder. Not reading some random blog posts on the internet.

    Thanks for reading!
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
←上一页
1 … 40 41 42 43 44 … 262
下一页→

Proudly powered by WordPress