开源日报 - Page 116 of 262

开源日报第579期：《玩中学 codecombat》

15 10 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《玩中学 codecombat》
今日推荐英文原文：《How to Become a Person Who Finishes What You Start》

今日推荐开源项目：《玩中学 codecombat》传送门：GitHub链接
推荐理由：写代码需要的最底层技能自然就是把积木堆在一起的逻辑思考力——这就意味着并不是要写代码才能习得这个技能。事实上，有很多更有意思的方法来锻炼它，比如游戏。这个项目用游戏和代码结合来训练新手们写代码的能力，但是你并不需要为自己一无所知发愁，只要稍微玩过一点游戏，就能很轻松的上手，剩下的就只是把代码积木堆积成想要的样子而已。

今日推荐英文原文：《How to Become a Person Who Finishes What You Start》作者：Shaunta Grimes
原文链接：https://medium.com/the-write-brain/how-to-become-a-person-who-finishes-what-you-start-edaf6bf98016
推荐理由：每个成功都是由无数个已完成的任务堆积起来的
How to Become a Person Who Finishes What You Start

And why it’s so important.
There are two kinds of people in the world. Those who do amazing things and those who really want to.

Just think about a standard New Years Resolution list.

Lots of people want to start a business, write a book, get organized, get out of debt, run a marathon. They put the same resolutions on their list year after year. Maybe for their whole adult lives.

But some people achieve those things. I’m convinced that there’s a skill set those people have cultivated. And right at the top of that set is this: They finish what they start.
Successful people are finishers.
That seems so almost stupidly obvious when I say it outright like that. Of course they finish. They’re successful. How can you be successful if you haven’t finished?

But honestly. If you want a successful business selling something you’ve created, you have to finish creating it. (See, I told you. Obvious.)

If you want to be published, you have to finish writing a book. If you want to be organized, you have to finish decluttering your house. If you want to be debt free, you have to finish paying off your debt. If you want to run a marathon, you have to finish training.

I belong to several groups where there are a lot of people who want to be successful. They want it so badly. It doesn’t matter what they want to be successful at, the point is that they really want it.

And then there are a few people in each group who are killing it.
The one big difference is that the successful people finish.
And I know. I know. There are a thousand reasons not to finish. You’re busy. You don’t have the money. You don’t have any connections. You don’t know how. You tried and it didn’t work. You’re not motivated.

All I’m saying is that if you look at someone who is doing what you want to do — someone successfully doing what you want to do — they’ve found a way around those reasons and they’ve finished.
Here’s how to become a finisher:

Muzzle your inner editor.
I’m a writer, so having an inner editor is obvious for me. I call her Blythe. But even if you’re not a writer, I bet you have an inner voice that constantly nitpicks and tells you that you suck.

Blythe’s favorite question is who do you think you are? She keeps my failures top of the mind, like it’s her job. She can be vicious, she can throw me so far off track that I can’t find my way back, and she has to be managed.

In my imagination, I put her in a bird cage, cover it with velvet, and refuse to let myself get caught up in perfectionism. Perfectionism is the death of creativity. That’s especially true when you’re trying to finish something you’ve never done before, when you don’t have any guarantees about the results.
Work consistently.
One more really obvious thing. Finishing requires work. Not sometimes. Not when you’re inspired or motivated. But consistently.

In my opinion, the best way to do this is to make a ridiculously small goal. My go to is ten minutes. Work toward finishing your project for ten minutes a day, everyday.

Eventually you’ll notice that once get over the hump between not working and working, you’ve worked for 20 or 30 minutes, or an hour. Or all day when things are really rolling. Small goals are magic.

Make your goal so small that it’s harder to skip it than it is to just do it.
Try gold stars.
Get a calendar and a pack of old-school star stickers. Give yourself one for every day that you meet your teeny, tiny goal. A visual representation of your string of successes is powerful.

Those stars add up to finishing. The only rules are that ten minutes are a minimum, not a cut off, and they have to move you forward. Wanting something really hard is not the same as working toward it.

Think about it this way. Imagine the thing you want to do as a walk from Los Angeles to New York City. If you walk eastward for ten minutes a day, you’ll get there. Sitting in a coffee shop thinking really hard about your walk for ten minutes won’t get you anywhere.

It might take you the rest of your life at that pace, but there’s no way for you not to finish if you keep moving forward and don’t quit.
Have a road map.
Here’s the system I use for making a very basic road map for my novels.

The difference between having that road map and not having it is massive. And the same goes, no matter what it is you need to follow.

Let’s go back to that walk between LA and NYC for a minute. If you don’t have a map, any wrong turn could take you miles and miles away from your goal. You’ll still be working, just not in the right direction.

Take it from me. That sucks.

If you want to be a finisher, it makes sense to start with a map. Just a few landmarks that you know you need to reach, so you can make your way from one to the next.

One of the best ways I know to make a map is to look for someone who has done what you want to do, and try to suss out their map. If you know them, just ask. Or look for people who have talked about their experience and take notes about their most important steps.
Find your people.
Connect with other people who are doing what you want to do — online or in person, or both.

I can’t emphasize this enough. There will be people who are active in the group and spend a lot of time planning their success or whining about their failure. Those are not your people.

Your people are the folks who are actually doing the work. Pay attention to them. When they offer you advice (this is important) implement it. Don’t just give it lip service, either. Really try it.

Ask questions. Do your own research though. Don’t ask questions that you can easily answer for yourself. If for no other reason than that you’ll be wasting a perfectly good opportunity to pick a smart, successful brain.
Get your hopes up.
Really. Get them up as often as you can.

I understand the urge to manage your expectations. Failure and rejection hurt and everyone wants to avoid pain. But the problem is that it’s nearly impossible to finish something if you don’t believe you can.

And it’s even harder to finish something great if you don’t have hope that will be, you know, great.

Think about it this way. Getting your hopes up is fun. It feels really good. And if you stumble or fail, refusing to get your hopes up means that you might be giving up the only part of the whole experience that didn’t suck.

Try to understand that getting your hopes up has value all by itself — separate from what happens next. Enjoy it and let it motivate you to finish what you’ve started.
Don’t let shiny new ideas derail you.
Beginnings and endings are easy. They’re exciting. Everyone loves starting something new and when you get to a certain point, you can see that you’re going to finish and things get exciting again.

But the middle? Yikes. The middle is hard. In fact, the middle is so hard that the Universe sends us a miracle to help us. A new idea so bright that of course they have to drop everything and start a new beginning immediately.

Don’t fall for it. That’s your brain giving you an out for the hard stuff. Take some notes, then keep working. Finish what you’ve started. It’s literally the only way to be successful.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第578期：《借力 free-api》

14 10 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《借力 free-api》
今日推荐英文原文：《Turn a Good Idea Into a Great One With the ‘Six Thinking Hats’》

今日推荐开源项目：《借力 free-api》传送门：GitHub链接
推荐理由：如果并不是为了学习，那么重复完成已有的成品就是不必要的事情。而当我们需要一些看起来很常见的功能（比如说获取油管某个频道的订阅数）时，一些已有的 API 就能帮我们简单的完成这个步骤。这个项目收集了网上可免费调用的 API，有些可能听起来还有些稀奇——比如台风轨迹的 API。借助这些 API 来完成一个步骤可比自己写一个快多了，把时间用在更重要的地方吧。
今日推荐英文原文：《Turn a Good Idea Into a Great One With the ‘Six Thinking Hats’》作者：Stephen Moore
原文链接：https://forge.medium.com/turn-a-good-idea-into-a-great-one-with-the-six-thinking-hats-4d94a0d0e4d1
推荐理由：六种帽子——从不同的方面来评价和完善一个想法
Turn a Good Idea Into a Great One With the ‘Six Thinking Hats’

A method to help you think big while staying realistic
One of my most life-changing moments took place back in college: I was giving a presentation on a product I had been developing over the semester, and midway through my talk, the professor interrupted with a question that caught me off guard: “Can we see the other concepts you worked on?”

My face turned red. The answer was no, because I didn’t have any. I was presenting the only idea I had worked on, because I thought it was great.

The instructor was less than impressed.

Walking out of the classroom a little while later, I looked down at notes my instructor had left for me on my assignment. There, scribbled in red pen, were instructions that would fundamentally change how I approach my ideas: “Research the Six Thinking Hats Method.”

Six Thinking Hats is a system designed in the 1980s by the psychologist and inventor Edward de Bono. The process involves wearing different imaginary “hats,” which represent different mindsets and emotions, allowing people to look at an idea from various angles with a different focus each time. “The main difficulty of thinking is confusion,” de Bono has said. “We try to do too much at once. Emotions, information, logic, hope, and creativity all crowd in on us. It is like juggling with too many balls.”

Originally developed as a way to make meetings more productive, Six Thinking Hats has since been adopted by the creative world as a way to critique ideas. The method allows you be creative and bold in a safe space, while forcing you to also be honest and realistic. While you can use it in meetings, I like to use it on my own — I think of it as having a personal team of consultants, each with their own expertise. But in this case, they’re all living inside my brain.

The Six Thinking Hats are as follows:
- The Blue Hat, also known as the Management Hat, is used at the start of the conversation to define the outlines of an idea, and at the end to summarize and draw conclusions. With this hat, you’re stepping back and getting the 10,000-foot-view of your idea, getting a sense of what to look at during and after the critique.
- Next comes the White Hat. When wearing this hat, you are looking for facts and data. This should be the first hat you use after setting your outline, as it allows you to establish relevant facts and information about your idea. Ask yourself: What is the concept, in its basic form? What is its purpose? Who does it serve? You should also use this hat to discover any gaps in your knowledge and understanding of your concept.
- The Yellow Hat brings a bit of positivity, and establishes the value of what you’re working on. Ask yourself: What is great about your idea? What benefits would it bring? Remember to keep your enthusiasm in check, though. Look for true value in the concept, and keep expectations realistic.
- The Red Hat comes next. This is where you can get a little emotional. With this hat on, you’re looking for the emotive response you get from your idea. Ask yourself: How does this make me feel? What is my reaction when I first see this idea? Then think outside yourself — what would a user’s reaction be, if they had never seen it before?
- Now, we flip things upside down and get ruthlessly negative with the Black Hat. Ask yourself: Why wouldn’t your idea work? Where are the issues and flaws? What are the drawbacks? By uncovering the potential problems, you can remove them and develop a stronger concept. Be careful not to bring in this hat too early in the discussions, as it can hinder any positive ideas that may come up.
- It’s time to let your mind off the leash with the Green Hat. Now that you’re aware of potential issues and flaws, how are you going to work through them? Ask yourself: What can you improve? What can be reiterated? Or is there a completely fresh idea forming in your head? If so, what is it? This is where you can get creative and begin fresh brainstorming. Use everything you have gained from the exercise to begin developing new ideas and directions.
The day I learned about the Six Thinking Hats was the day I learned an important, if uncomfortable lesson: Even if you’re amped about an idea — even if you’ve run it through your head a hundred times, sketched out a logo, and prepared to release it to wild acclaim — that idea may still suck. Or at the very least, it may need to be seriously refined.

When you hold on too tightly to your original concept, because of your pride or your ego, it blinds you to the possibilities ahead. The Six Thinking Hats can transform your idea from something mediocre to something good, and from something good to something that could change your life.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第577期：《有问才有答 fe-interview》

13 10 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《有问才有答 fe-interview》
今日推荐英文原文：《When the Bill Comes Due》

今日推荐开源项目：《有问才有答 fe-interview》传送门：GitHub链接
推荐理由：众所周知，学以致用才是巩固知识的好办法。只学过一遍很容易就随着时间变成山回路转不见妹，雪上空留蝠行处——也就是记得学过，但是不太记得学了什么的情况。使用知识的方法因人而异，这个项目提供了一个不错的方式——问问题，通过回答面试题来巩固所学，不过这个项目的主题是前端。回答面试题不仅能够巩固自己的知识，某种意义上也算是为将来可能的面试做准备，可以一举两得。
今日推荐英文原文：《When the Bill Comes Due》作者：Ryan Nehring
原文链接：https://medium.com/better-programming/when-the-bill-comes-due-6f027d06f66
推荐理由：技术债务，一言以蔽之——就是历史遗留问题，而且迟早要解决它
When the Bill Comes Due

The necessity and dangers of technical debt

“Move fast and break things.”—Mark Zuckerberg
In fairness, as quotes go, that one is pretty excellent. It’s succinct, empowering, and motivating. It’s also desperately in need of a second sentence along the lines of, “Once it works, go back and do it correctly!”

Technical debt didn’t start with Zuck’s bold mission statement. He simply made a motto out of what most of us programmers have been doing since time immemorial. We build things, but more than that, we often have to invent the way we build them as we build them.

That’s a messy process.

Oftentimes, the problems we’re building solutions for are so large or complex that we’re writing code just to see if what we’re envisioning is even possible. This proof-of-concept stage is one of my favorite parts of programming. Prototyping an idea can be immensely satisfying, although is rarely well planned, and this is where the origin of most of our technical debt begins.
From Prototype to MVP
Development cycles move fast. For many reasons, the excitement around a working proof-of-concept can quickly become a sprint to a minimum viable product. Whether you’re trying to beat a competitor to market or think you’re onto the next big thing, it’s rare for developers to slow down at this point.

This makes sense. The world of development can be capricious and ephemeral, and speed does matter. It’s in this phase of the process that technical debt begins to really rack up. Quick-fix code solutions designed to get a feature up and running or to find a viable integration of outside data rarely hold up well once scaled.
Broken Promises
Almost nobody lies to themselves as regularly or effectively as a programmer. While accruing technical debt, we intrinsically know we’re taking shortcuts, but we promise ourselves we’ll be back to fix this as we sail forward onto the next feature.

This creates an exponential chain reaction. As your project takes real shape, there is always another feature (or features) on the horizon. This isn’t a bad thing in and of itself; in fact, it’s usually a sign that what you’re working on has value, but as you leave each barely functional feature behind to start on the next one, your tech debt inches ever higher.
Technical Debt Charges Interest
Admittedly, it’s a bit of a cliche, but it’s also true. The longer you ignore that pile of tech debt, the larger it gets, but also the harder it gets to address. Undoubtedly, new features and functions have changed the landscape of your application, and figuring out how to wire everything back together becomes difficult.

Shoddy variable naming practices, insecure data access methods, buggy third-party libraries, etc. all begin to make that transformation from a molehill to a mountain. It’s not uncommon for application state to get buggy or UI issues to crop up at this point.
A Necessary Evil That Shouldn’t Be Ignored
In practical terms, technical debt is unavoidable. It’s a necessary evil empowering us to move quickly towards a better understanding of the big picture. Balancing when and how to address technical debt is a difficult decision that shifts from project to project.

But address it you must.

Ignored technical debt will wreak havoc as your project moves into launch. Under the strain of multiple concurrent users or unanticipated user workflows, the cracks will show. In the best of all worlds, this can be as minor as UI anomalies, but unaddressed technical debt can also expose user data. If your application tracks sensitive personal user information, this can be catastrophic.
Plan for the Fact You Didn’t Plan Enough
So what’s the right approach? Moving forward explicitly understanding that you perhaps haven’t planned out your project as fully as you’d like to is a good first step. In short, don’t lie to yourself.
- Take time after getting any feature working to make a couple notes on what needs to be addressed. Where are the shortcomings? What won’t scale well? Where are the fragile points? Even something as simple as having a running log will help hold you accountable for actually correcting those issues.
- Seek code review. Other developers can point out fragile points you might not recognize. Their experience can guide you in seeing the unexpected issues you may be creating along your way.
- Schedule refactor time. Build into your workflow time to go back and revise and optimize. You’ll always have something new to do, so if you don’t schedule time to address technical debt, you’ll likely ignore it.
Lastly, don’t despair. If you’re accruing technical debt, it probably means you’re building something cool and useful with room to grow. That’s an achievement; that’s why we do what we do!

Technical debt can cause real problems, but it’s not an 800-pound gorilla. It’s your code. You wrote it. Go fix it and make sure it performs the way you need it to, under all circumstances. Then go build that next great feature!
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第576期：《心诚则灵 EagleEye》

12 10 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《心诚则灵 EagleEye》
今日推荐英文原文：《Clean Classes》

今日推荐开源项目：《心诚则灵 EagleEye》传送门：GitHub链接
推荐理由：给这个项目一张照片，以及一些小小的情报，它就会从网络世界……里的脸书推特这些社交媒体上找出你想找的这个人。尽管社交网络上的情报大部分都不怎么靠谱，目标人物到底是不是你想找的人还两说（基于这一点，实在不推荐用于寻找心仪异性的社交账号），但是最起码这个人的信息一定和你给的情报有共同之处——兴许网络世界里真的存在着一个使用这个名字，上传了这张照片的人也说不定。
今日推荐英文原文：《Clean Classes》作者：Dhananjay Trivedi
原文链接：https://medium.com/better-programming/clean-classes-43b46da37f39
推荐理由：在面向对象的编程中写出干净的类
Clean Classes

Things that should be taught along with OOPS

The Clean Code series has been going really well! We’ve looked at how to write lines and blocks of code, how to write functions, and how to make the modular.

All these blocks of code combine together to form a higher level of code organization, which we refer to as Classes.
```
// Structuring a Standard Java Classpublic class ClassName {

  // Static constants  
    // Static variables  
    // Private constants  
    // Private instance variables 
    // Public functions()  
    // Private utilities functions()}
```
We want to keep our functions ‘Private’ when we possibly can, but that doesn’t mean every time! We sometimes want our functions to be accessible through tests. We use these access modifiers to achieve encapsulation. Losing encapsulation in order to make your functions accessible by tests should always be the last option.
Two rules while writing classes
1. Classes should be small
2. Classes should be smaller than that!
Smaller is the primary rule when writing classes, while in functions we go for “how small?”

We measure functions by the number of lines, while we measure classes by the number of responsibilities.

We should also be able to write a brief description of the class — in about 25 words, without using the words “if” “and” “or” “but”.

Let’s look at an example:
```
public class GodClass extends JFrame implements MetaDataUser{

    public Component getLastFocusedComponent()

    public void setLastFocused(Component lastFocused)

    public int getMajorVersionNumber()

    public int getMinorVersionNumber()

    public int getBuildNumber()
}
```
The class seems small but has diverse responsibilities: managing focus and getting the build number.
Remember the SRP — Single Responsibility Principle?
The class or module should have only one responsibility — one reason to change. SRP is one of the more important concepts in OO design. It’s also one of the simpler concepts to understand and adhere to.

Yet oddly, SRP is often the most abused class design principle because getting the software to work and making software clean are two very different activities.

Anyways, let’s break this class into two separate classes:
```
public class Version {

    public int getMajorVersionNumber()

    public int getMinorVersionNumber()

    public int getBuildNumber()
}
```
And the other…
```
public class FocusedComponent {
            public Component getLastFocusedComponent()
            public void setLastFocused(ComponentlastFocused)
}
```
There! That looks so clean and small! The problem is that too many of us think that we are done when the program works. We fail to switch to the other concerns: organization and cleanliness.

We move on to the next problem rather than going back and breaking the overstuffed classes into decoupled units with single responsibilities.

Do you want your tools organized into toolboxes with many small drawers, each containing well-defined and well-labeled components? Or do you want a few drawers that you just toss everything into?
Cohesion
There will be instance variables in our classes and there will be functions that will be manipulating these instance variables. The more variables a method manipulates, the more cohesive that method is to the class.

A class where each instance variable is being manipulated by each method is maximally cohesive. Hence, cohesion is just a measure of how much the variables and methods are logically related to each other.

When cohesion is high, it means that the methods and variables of the class are co-dependent and hang together as a logical whole.

The better the cohesion, the better the program design.
```
public class Stack {

    private int topOfStack = 0;    List<Integer> elements = new LinkedList<Integer>();

    public int size() { 
        return topOfStack;
    }

    public void push(int element) { 
        topOfStack++; 
        elements.add(element);
    }

    public int pop() throws PoppedWhenEmpty { if (topOfStack == 0)
        throw new PoppedWhenEmpty();
        int element = elements.get(--topOfStack); 
        elements.remove(topOfStack);
        return element;
    }
}
```
In this example, the push() and pop() both are mutating the two instance variables elements and topOfStack. Hence it’s quite cohesive.

Maintaining cohesion requires breaking your class into a lot more smaller atomic classes. Whenever class loses cohesion, that’s a hint for you to split them.

There are multiple types of Cohesion.
- Co-incidental cohesion — Unplanned, random which is an outcome of modularization of code. Since it’s unplanned, it’s not acceptable as it can be confusing to the programmers.
- Logical cohesion — When you plan and put logical related statements and instructions in one module.
- Procedural cohesion — When elements of a module are put together to perform one task.
- Communicational cohesion — When elements are grouped together which are executed sequentially and work on the same data.
- Temporal cohesion — When elements are structured so that they are processed at a similar point of time, it is called temporal cohesion.
- Sequential cohesion — When the output of one element serves as input to the next one, and they are structured together, it is called sequential cohesion.
- Functional cohesion — When elements contribute to make a single well-defined function.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/

开源日报第579期：《玩中学 codecombat》

How to Become a Person Who Finishes What You Start

And why it’s so important.

Successful people are finishers.

The one big difference is that the successful people finish.

Here’s how to become a finisher:

Muzzle your inner editor.

Work consistently.

Try gold stars.

Have a road map.

Find your people.

Get your hopes up.

Don’t let shiny new ideas derail you.

开源日报第578期：《借力 free-api》

Turn a Good Idea Into a Great One With the ‘Six Thinking Hats’

A method to help you think big while staying realistic

开源日报第577期：《有问才有答 fe-interview》

When the Bill Comes Due

The necessity and dangers of technical debt

From Prototype to MVP

Broken Promises

Technical Debt Charges Interest

A Necessary Evil That Shouldn’t Be Ignored

Plan for the Fact You Didn’t Plan Enough

开源日报第576期：《心诚则灵 EagleEye》

Clean Classes

Things that should be taught along with OOPS

Two rules while writing classes

Remember the SRP — Single Responsibility Principle?

Cohesion