开源日报 - Page 114 of 262

开源日报第587期：《小试牛刀 react-demos》

23 10 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《小试牛刀 react-demos》
今日推荐英文原文：《Your Job Doesn’t Have To Define You》

今日推荐开源项目：《小试牛刀 react-demos》传送门：GitHub链接
推荐理由：在学习某个新玩意的时候我们都会写下各种各样的 demo 来尝试一些想法，这能帮助我们熟记概念理清思路等等。这个项目是一个关于 React 的 demo 合集，可以很好的作为原型加以改造验证自己学习 React 时的想法，尽管它们覆盖的知识点有限，不过如果还没有边看文档边开 demo 试水的习惯的话可以考虑从此开始，毕竟有的时候比起琢磨各个特性组合的结果，不如直接写个 demo 看看结果来验证猜想来的更快。
今日推荐英文原文：《Your Job Doesn’t Have To Define You》作者：Claire J. Harris
原文链接：https://medium.com/swlh/your-job-doesnt-have-to-define-you-a7dc91b022e9
推荐理由：工作是赚钱的工具，而不是生活的全部
Your Job Doesn’t Have To Define You

Think of it as corporate sponsorship for the rest of your life
It’s the first question you are asked by strangers: “So what do you do?” I know it’s just small talk, and conversation has to begin somewhere — and yet, it’s somewhat baffling that the answer to what we “do” is limited to the activity that fills our time on weekdays between 9am and 5pm. Namely, our job.

I always struggle to answer this question. For three days a week, I am paid by an employer to write brochures, letters and websites for financial institutions. (Yes, that is every bit as interesting as it sounds.) I sometimes tell people “I work in finance” but that is, of course, nonsense — the picture it conjures up doesn’t in any way represent the reality of working from home in comfy pants and taking naps after lunch. Also, I know nothing about finance.

Sometimes I tell people, “I’m a copywriter” and then they immediately say something about Mad Men. I write copy but I don’t make ads or drink bottomless tumblers of whiskey or throw around ideas for commercials with men in suits. I don’t even see any other humans during my work days.

I struggle to explain to people why I only work three days a week — and it leads to a rambling response about how I might work work (ie get paid) for those three days but I really work seven days a week because I write on all the other days too. (“Please don’t think I’m lazy” is the subtext.)

Then they ask what of mine they’ve read/watched/remotely heard of — and the answer is… probably nothing. In which case, can I call myself a writer when people ask what I “do”? Can you call yourself something that you only occasionally get paid for?

When I lived in New York a few years ago, I was struck by the fact that people defined themselves by their aspirations. If I asked someone what they did, they invariably told me they were an actor, dancer, writer — and not, in fact, a waiter, nanny, or bartender.

At the time, I thought this was pretentious — as though there is a shame or stigma attached to the casual work you take on while you’re staking everything on trying to turn your dream job into reality. What’s wrong with being a waiter anyway?

But now I think maybe they were right: my creative writing has more to do with who I am than my copywriting. I switch off from my day job as soon as I clock off, whereas my own writing projects constantly consume my thinking, even if they never eventuate into published/filmed works.

I often think about chucking in my day job and pursuing one that is more meaningful to me. Using my writing skills to work on grants for an NGO, for example, or becoming a journalist.

But if there was one piece of advice I took from film school, it was that the best way to create art is to have a relative well-paying job that you could afford to do only a few days a week. Time is the most valuable resource you have — and if I left this job for another one that consumed my time and my thoughts, there would be nothing left to give to my writing.

This, of course, puts a lot of pressure on my writing, and on the four days a week that I spend not getting paid. In modern western society, we seek fulfillment from our jobs in a way that perhaps generations before us didn’t — and yet the sole purpose of mine is to give me the freedom to do something else more meaningful with the rest of my time.

We are also valued according to our economic contribution, and as all artists know, it is rare for creativity to be financially rewarded. When I find myself talking about my job at parties, I find myself justifying this lack of economic contribution — what makes me think that I/my writing is so special, that I should only have to work three days when everyone else is slugging it out five days a week?

The truth is, I’m probably justifying it to myself much more than the stranger who by this point into my monologue is usually trying to find a way to exit the conversation.

If I traded this time for a different job, there is no guarantee that I would find it any more fulfilling than the one I currently have. Even if I didn’t write, I would still rather have less money and more time to do things outside of work — no matter what that work was — for as long as I’m in a position where that is financially viable.

As a friend (and fellow artist) once told me, “Don’t think of it as a job. Think of it as corporate sponsorship for your creative life.” So I guess I should be grateful to the finance industry for generously offering to sponsor my writing.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第586期：《大地图 Minecraft-Overviewer》

22 10 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《大地图 Minecraft-Overviewer》
今日推荐英文原文：《Why Should I Even Bother With Full-Stack Development?》

今日推荐开源项目：《大地图 Minecraft-Overviewer》传送门：GitHub链接
推荐理由：相信玩了有些时日的 Minecraft 世界都已经在不少地方被玩家改造过了，而想要一口气看清这些变化在游戏内似乎并不是那么容易。这个项目可以为你的世界生成一个美观的可交互的 html 地图，可以轻松的一览地表全貌，看看自己已经完成的建筑或者是大家瞎造的奇观都很方便，虽然一个服务器里的大家都有弃坑的时候，但是 MC 服务器里的地图就像现实世界里的团队合影一样，是大家一起相聚过的证据。
今日推荐英文原文：《Why Should I Even Bother With Full-Stack Development?》作者：Frank Zickert
原文链接：https://codeburst.io/why-should-i-even-bother-with-full-stack-development-142b9c4c7c3f
推荐理由：同时掌握前后端的技能并非坏事，最起码多一分能力就能多一分工资
Why Should I Even Bother With Full-Stack Development?
Writing code has long been the biggest challenge of software development. How do you combine if-then-else-structures with loops to solve a business problem?

The user interface design was done on the side. The developer was the decisive factor. What she was able to build was what the software looked like. Some developers had talent concerning user interfaces. Some did not.

This changed with the rise of the internet. Graphical user interfaces moved into focus. Even more importantly, those user interfaces did not need to be programmed. The Hypertext Markup Language (HTML) and Cascading Style Sheets (CSS) enabled designers to build websites. These designers were technically skilled. Of course. But they did not need to be programmers.

At the time, JavaScript was not mandatory. Not very long ago, the company I am working for distinguished “front-end” developers. In those who do the graphical design with HTML and CSS (only). And in those who are capable of working with JavaScript.

JavaScript development was a hacky concept. Front-end developers manipulated the Document Object Model (DOM). That is the page’s hierarchical structure of the HTML-elements. They added, removed, and changed the classes and the other attributes of an HTML-element. Seen from the eyes of a software engineer, this was all hacky! It did not have anything to do with the craft of software engineering.

Would you let a JavaScript developer implement business logic? Would you let her do something you consider critical for the success of your business?

For heaven’s sake, no!

Implementing business logic was left to the back-end developers. These developers took the styled HTML and inserted it into the business logic that they wrote. PHP became popular for making it quite easy to render HTML on the server-side.

But something happened!

Maybe caused by the introduction of HTML5 and “Asynchronous JavaScript and XML” (AJAX). Maybe caused by the advent of Ecma Script. Websites started to act and behave more like applications. An increasing proportion of the business logic was closely coupled to the user interface. With the greater responsibility, frameworks evolved in JavaScript. Front-end developers lost their hacky image and became software engineers, too.

Supposedly, front-end development became more of software engineering than back-end development is today! Back-end got reduced to work with databases, provide the data through APIs and take care of DevOps. They cope with all the things that require interconnectivity and integration. Working with different APIs sometimes is… hacky! They need to make sure that all the details work together. They implement specific code for a very specific API.

But moving business logic to the front-end did not free the capacities at the back-end. For plausibility, security, and integrity, all the logic still had to run at the server-side. Because the front-end could be edited by attackers. The code had to be duplicated!

Of course, writing code twice comes with problems. There is the avoidable effort of doing things twice. And there is the risk of inconsistencies between the logic at the front-end and the back-end side.

Full-stack development promises to avoid duplicate code and thus, prevent those inconsistencies.

There is a good chance that this promise will be kept.

JavaScript runs on any modern browser. With Node.js, it runs on the server, too.

React.js removed the boundaries between HTML and JavaScript. It uses the Javascript Syntax Extension (JSX) that complements basic Javascript source code with HTML.

Styled-Components added a convenient way of styling your React-components. There’s no need for global style sheets anymore.

With Infrastructure-Components, you can write REST-services, as well as database schemes and queries. You can even configure your serverless infrastructure.

The following picture depicts how the React.js-stack (including libraries) covers pretty much the full technology stack.

Full-Stack React

Now, you can use React from the very front-end of your application to the back-end and even DevOps. Within the same code. Without duplicates.

The technology stack has never been so homogenous. From that perspective, it has never been easier before to become a full-stack developer.

With the technology stack moving closer together, the demand for full-stack developers even rises. Consider isomorphic React apps. These are apps that use the same React-components to run on the server and the client-side. If you considered yourself as either a pure front-end or a back-end developer, you would not be up for that challenge.

This is less of a programming challenge. It is not about learning many different programming languages. This is rather a challenge to the skills and the mindset.

Creating intuitive user interfaces requires more than HTML, CSS, and JavaScript. You need to have the ability to craft compelling user experiences.

Writing business logic requires more than combining if-then-else-structures with loops. You need to understand the implications of the logic you implement.

Writing full-stack applications requires you to understand software architectures. You need to understand how to compose your software. The code of your front-end and back-end might be identical. But it matters whether the code runs on the front-end or the back-end. It matters for performance, security, and sometimes even meaning.

The demand for full-stack developers does no longer result from the businessmen’s urge to hire fewer developers who can do more. The demand for full-stack developers stems from the increasing power of the tools. React is no longer a front-end library. Today, you can use React to write back-end software and to configure your infrastructure.

Full-stack development does no longer require multiple programming languages. But it still requires versatile skills. It requires you to think and act like a full-stack developer.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第585期：《联系 KnowledgeGraphData》

21 10 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《联系 KnowledgeGraphData》
今日推荐英文原文：《Tips for Writing Self-Documenting Code》

今日推荐开源项目：《联系 KnowledgeGraphData》传送门：GitHub链接
推荐理由：世间万物皆有联系，这些联系组合成一张大网，网罗了世界上的一切。这个项目提供了一个开源的知识图谱，也就是将事物与事物用关联关系相连组合成的一个图谱。而这样一个图谱对让机器认识世界上的一个事物很有帮助——毕竟它们没有常识也没有感官，我们需要将一切相关信息都与这个事物连接起来提供给机器，才能让它正确的认识这个事物。最容易想到的成果就是将其用于问答机器人了，这个项目也基于这个图谱完成了一个问答机器人，有兴趣的朋友可以尝试一下。
今日推荐英文原文：《Tips for Writing Self-Documenting Code》作者：Mike Cronin
原文链接：https://itnext.io/tips-for-writing-self-documenting-code-e54a15e9de2
推荐理由：把代码写的像文档一样整齐——并不是任何时候都需要把大小性能什么的压到极限的
Tips for Writing Self-Documenting Code

How to write code that other developers can actually read
Self-documenting code is just a fancy way of saying “readable code,” and readable code is what keeps you from losing your mind at work. It’s no replacement for real docs or a well placed comment, but it never hurts to write better code. Let’s talk about some habits that will make your work easy to understand.
Don’t use magic numbers
Look at this and tell me what it means:
```
if (students.length > 23) {
```
What is that 23? How am I supposed to know what that is, am I Jim Carrey? That 23 is a magic number, which is a terrible name because it sounds fun, but it is not. It means that there’s a number that looks important, but has no context. Always give a name for numbers:
```
const maxClassSize = 23;
if (students.length > maxClassSize) {
```
Now it reads: if we have more students than the maximum amount allowed, do a thing. Neato. This actually leads into my next point:
Use clear variable names
I don’t know why, but I used to get super self-concious about writing long variable names. Which was dumb, becuase rStuNms and fStuNms are utterly terrible compared to rawStudentNames and filteredStudentNames. They seem too long, but I am telling you: after 2 weeks of not looking at the code you will not remember a single acronym. A variable name is extremely important because it’s your chance to tell your reader what your code is doing:
```
const fStuNms = stus.map(s => s.n) 
// vs
const filteredStudentNames = students.map(student => {
  return student.name;
});
```
That’s a contrived example, but you get the idea. Another helpful tip is to use naming conventions. If your value is a boolean, start with is or has, like isEnrolled: true. If your value is storing an array, the name should be plural, eg students. Numbers should start with min or max if possible. For functions, there should be a helpful verb in front, like createSchedule or updateNickname. And speaking of functions:
Refactor with tiny, named functions
Variables aren’t the only places to add helpful explanations, function names are great too! I used to think that functions were only for DRYing up your code, but recently I had my mind blown when I learned that functions really shine when they’re used for readability. Look at this code for a second and tell me what’s going on:
```
const handleSubmit = (event) => {
  event.preventDefault();
  NoteAdapter.update(currentNote)
    .then(() => {
      setCurrentAlert('Saved!')
      setIsAlertVisible(true);
      setTimeout(() => setIsAlertVisible(false), 2000);
     })
     .then(() => {
       if (hasTitleChanged) {
         context.setRefreshTitles(true); 
         setHasTitleChanged(false);
       }
     });
   };
```
It’s possible, but how about:
```
const showSaveAlertFor = (milliseconds) => () => { 
  setCurrentAlert('Saved!')
  setIsAlertVisible(true);
  setTimeout(
    () => setIsAlertVisible(false), 
    milliseconds,
  );
};
const updateTitleIfNew = () => {
  if (hasTitleChanged) {
    context.setRefreshTitles(true); 
    setHasTitleChanged(false);
  }
};const handleSubmit = (event) => {
  event.preventDefault();
  NoteAdapter.update(currentNote)
    .then(showSaveAlertFor(2000))
    .then(updateTitleIfNew);
  };
```
Boom, so much cleaner. All we did was scoot a few lines of code into functions and it improved dramatically. showSaveAlertFor is even a function we can use elsewhere if we want to. The lines of code are scooted up and away into function definitions, but you don’t need to read them directly unless there’s a problem. At the high level, we have a human readable chain of events. Function definitions are also another great way to label variables. setTimeout takes a function and number of milliseconds, but now we’ve clearly added it ourselves to be extra helpful.
Add useful test descriptions
Probably the least talked about way of sneaking documentation into code is with tests. Suppose we have this function:
```
const getDailySchedule = (student, dayOfWeek) => { 
```
Let’s pretend this is a runner function made up of a bunch of other functions, so it does a lot: It retrieves the daily schedule; if the day of the week is a weekend it returns an empty array; if the student has detention it sticks it onto the end of the schedule; and if the student isn’t enrolled in the school, it prints a link to that Mean Girls Gif.

If you tried to put that paragraph as a comment, you’re going to get some weird looks. But you know where that paragraph would look great? In tests:
```
describe('getDailySchedule tests', () => {
  it("retrieves the student's full schedule", () => { 
  it('returns an empty array if given a weekend day', () => {  
  it('adds detention if a student got one that day', () => {
  it('prints a gif link if student not enrolled yet', () => {
```
This is hands down the easiest way to straight up put comments into code without actually adding any comments.
Bottom line: readable over cleverable
Being a good developer doesn’t mean writing the cleverest code, it means being a good teammate. Quality software is rarely developed alone, eventually other people will need to read your code. And even if you’re working alone, you-right-now and you-in-two-weeks are almost different people when it comes to remembering code. There are lots more ways to write readable code, like adding good comments, but the most important thing you can do is just start thinking about it.

happy coding everyone,

mike
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第584期：《车轱辘 gulu》

20 10 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《车轱辘 gulu》
今日推荐英文原文：《Good Developers are Smart, not Clever.》

今日推荐开源项目：《车轱辘 gulu》传送门：GitHub链接
推荐理由：要向制造一个轮子，必然需要了解很多轮子。这个项目是一个前端 UI 框架——也就是一个轮子，不过这个并不是拿来正式使用，而是给新人来阅读源码的。框架的用户千奇百怪，所以编写框架不仅要追求高性能，也要注意代码的整洁可读性等等各方面内容，而读一读现有框架的源码正好适合用来学习这些。
今日推荐英文原文：《Good Developers are Smart, not Clever.》作者：Ravi Shankar Rajan
原文链接：https://medium.com/swlh/good-developers-are-smart-not-clever-4d1d4bde8868
推荐理由：变强就是把努力用在正确的地方——还有就是别停止努力
Good Developers are Smart, not Clever.

Good code is expressive, not impressive.
One of my first lessons as a developer 15 years ago was a simple, short message.
“Good code is expressive, not impressive”
I remember retorting back, “What is the difference?” and he had said.

“Expressive” means clear-cut, definitive and specific. So writing an expressive code will necessarily have to address a specific problem. There is a purpose behind investing time and effort in creating it and it does exactly what it was intended for.

”Impressive” on the other hand means to leave a stamp or an imprint. So writing an impressive code with complex constructs and algorithms, while it might satisfy your ego and get you the wows, eyebrow-rolls, and claps, it might turn out to be a pain of unmitigated proportions for the guy who is going to maintain your code in the future. And if he happens to be a psychopath who knows your address, only God can save you then from his wrath!

That is why good developers are smart, not clever. A smart developer combines natural intelligence with an ability to judge the consequences of his action in the future. They know exactly what code they are writing, why they are writing and how the code will impact in the long run. In short, they are not Band-Aid developers. They believe in fixing the disease once and for all.

Clever developers, on the other hand, are fast, quick and know all the dirty ways in the world to make a code “work”. They combine natural intelligence with an ability to find supersonic solutions to every problem at hand. But over time the bandages and duct tape build up and one day the code simply crashes along with the reputation of all developers who had worked on it. That is why Steve McConnell had righty said.
“Programming is not like being in the CIA, you don’t get credit for being sneaky.”
And smart developers do not do anything sneaky. They write code, which is boring, simple and easy to understand. Nothing more, nothing less.

And here are some great things smart developers do.
They keep it simple.
Martin Fowler had righty said.
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
Developers sometimes get the feeling that they need to prove. They need to show to others what they can do and are capable of. This makes them search for complex solutions to every problem when the simplest solution would be staring right at their faces. This is the worst mistake any developer can make.

Smart developers write straightforward code. Straightforward code is easy to maintain, optimize and refactor in the future. It does nothing crazy or unexpected and everyone reading it knows precisely what it does. Novel and unusual algorithms and approaches typically look great during a coffee-fueled all-nighter but fail miserably in real-time situations.

Remember whenever you write code and a little bird called ego starts tempting you, ask yourself one simple question.

“If I come back and work on my code after 2 months, will I be able to understand it?” If the answer is yes, go for it by all means but have pity on your fellow programmers by putting in proper comments, naming variables properly and modularizing it as much as possible so that it does not need to be explained.
Good code is like a joke. If it has to be explained, it is not a good one.

They know when to improve any code.
Edgar Dijkstra has rightly said.
“Focus on WHY instead of WHAT in your code will make you a better developer.”
That said, there are multiple ways to optimize code. Each of the possibilities comes from using more memory, faster execution or different algorithm/logic. And whenever possible, smart developers make this choice wisely.

But before starting any code improvement activity, they follow the golden principle of “don’t”.

Why should I do it? Is the program good enough already? Knowing how the program is going to be used and the environment in which it runs, is there any benefit of making it faster? These are some questions you should ask prior to optimizing the code.

Yes. Optimization only makes sense in terms of effort and cost if the program is important and it is genuinely slow and there is some expectation that it can be made faster while maintaining robustness, correctness, and clarity. A fast program that gets the wrong results is of no use to anybody. Effectively optimized software has more advantages than disadvantages, but if you do the optimization wrong, the opposite is true.
Remember whatever you are improving should be measurable. Intuition is always a very lousy guide on which to depend on.

They maintain rather than build code.
Vicky Gundotra hit the nail bang on the head when he said.
“You start coding. I will go find out what they want.”
Smart developers do precisely that. They start by searching for the solution in what is available. While some of us like to get on our high horse about rebuilding things the “right way.” in most cases we end up burning efforts in reinventing the goddammed wheel.

Do not be afraid to search. Looking up for already implemented solutions online or in your code database is very helpful in learning the methods prevalent for similar situations and the pros and cons associated with them. That is why smart developers spend a lot of time reading code before writing. Writing a brand new code is always expensive in terms of time, money and emotional energy. Don’t do it unless really required.

So when you are trying to complete a task, check to see if someone else has already solved the problem. You are not cutting corners here. You are cutting the effort here.
They challenge themselves.
Aristotle has rightly said.
“If something that you are doing does not challenge you, then it does not change you.”
Smart developers challenge themselves, more precisely the code they had written at every opportunity. They are humble enough to admit that no code is the best code ever created.

They do not settle down in a comfortable rut and deploy the same pattern every time. They consciously avoid their coding preferences to degenerate into blind dogma. They always look for ways and means to do things better and if this means learning something new, they are all game for it.

Remember, Smart developers, are not enamored by shiny ideas or jazzy features. They are pragmatic enough to realize that there is no perfect solution and every great feature or amazing hack comes with downsides.
Lastly, they are not afraid to ask for help.
Sophocles has righty said.
“If we always helped one another, no one would need luck.”
As developers, we like to think of ourselves as smart people. In fact, some of us are pure geniuses also. But having said that, we do have a tendency to think that we know everything and we can think of everything within our minds. After all, who will want to say, “I don’t know” in a meeting? Who will want to admit that the new functionality to be deployed is all Greek to you?

Instead, you tell yourself: “I’ll figure it out myself. I have always relied on myself in the past. I can do it again.”

Smart developers don’t do that. They know when to ask for help and when to use their own minds. They know precisely that any further delay in asking for help will lead to anxiety and subsequently put pressure on everybody in the team to meet the deadlines. That is why they are not afraid to expose their own ignorance and ask for help whenever required.

Remember asking for help is not a question on your capability. It just reinforces the confidence that others have in you that, you will do whatever it takes to complete your work on time and with the right results. You come across as a go-getter, confident developer who wants to change himself every day for the better.

As Kubra Salt has righty said.
“Asking questions is the first way to begin change.”

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/