开源日报 - Page 120 of 262

开源日报第563期：《踩坑 wtf-html-css》

29 9 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《踩坑 wtf-html-css》
今日推荐英文原文：《A List of Fun Things You Can Build as a Developer》

今日推荐开源项目：《踩坑 wtf-html-css》传送门：GitHub链接
推荐理由：对于刚刚接触 html+css 的新人来说，面对满屏密密麻麻的标签和规则难免会遗漏一些细节。这个项目是作者在这方面实践学习时找出的容易疏忽的地方，包括浮动和按钮等等。尽管多掉几次坑能够长记性，但是摔一次花大半天爬起来总是有些划不来呢……在这看到了之后就留个心眼，踩坑的时候就来这查一查吧。
今日推荐英文原文：《A List of Fun Things You Can Build as a Developer》作者：Daan
原文链接：https://medium.com/better-programming/a-list-of-fun-things-you-can-build-as-a-developer-bc07fd21c6e3
推荐理由：既然有了这能力，就应该干些有意思的事情
A List of Fun Things You Can Build as a Developer

Improve as a developer by getting your hands dirty
One becomes a beginner after 1,000 days of training. One becomes a master after 10,000 days of practice.

This is a quote from Mas Oyama that sums things up pretty well. The secret to being a great developer is by putting in the effort. Spending a lot of hours behind the keyboard and getting your hands dirty will make you grow as a developer.

Here are 7 projects you can work to help you improve as a developer. Feel free to pick your own tech stack — use whatever you like.
Project 1: Pac-Man

Building Pac-Man is a great way to get a feeling of how games are developed from a very basic perspective. This could be made with a JavaScript framework like React or Vue.

Things you will learn:
- Movement of entities
- Detecting keys being pressed
- Collision detection
- You could go the extra mile by adding steering behavior to the ghosts
You can find the example GitHub repository here（https://github.com/mbfassnacht/pacman-react）.
Project 2: User Administration

Check the GitHub repository here（https://github.com/indreklasn/laravel-5.4-crud-example）

Making a CRUD application for user administration will teach you a lot about the fundamentals of development. This is especially useful for developers that have just started.

What you will learn:
- Routing
- Handling forms and validation of user input
- Interacting with the database — create, read, update, and delete actions
Project 3: Check the Weather at Your Location

Check the GitHub repository here（https://github.com/SwiftTsubame/iOS11Weather）

If you want to get started with building apps, a weather app is a perfect start. This project could be made in Swift.

Besides getting some experience with building an app, you will learn:
- Interacting with an API
- Using geolocation
- You could make this more dynamic by adding a text input where users can enter a location to check the weather at that location
One API you could use to get the weather data from is the OpenWeather API. You can find more information about the OpenWeather API here.（https://openweathermap.org/api）
Project 4: Chat Box

My own chat box in action in two browser tabs

Building a chat box is the perfect way to get started with sockets. You have a lot of different options when it comes to choosing your tech stack. Node.js could be one of the ways to go.

The biggest take away from this project is that you will learn how sockets work and how you can implement them.

If you are a Laravel developer that wants to work with sockets, I’ve written an article（https://medium.com/swlh/guide-to-using-sockets-in-your-laravel-application-596d42367f0e）about how you can implement a chat box in Laravel using sockets.
Project 5: GitLab CI

source（https://vshn.ch/en/blog/automated-build-pipelines-with-gitlab-ci-and-appuio/）

If you are new to continuous integration (CI), it is a good idea to fiddle around with the GitLab CI. Set up multiple environments, and try to get some tests running in your pipeline. This is not a very program heavy project, but I’m sure that you will learn a lot. A lot of development teams use CI nowadays, and it is a great tool to have under your belt.

What you will learn:
- Getting to know GitLab CI
- Configuring a .gitlab-ci.yml that tells the GitLab runner what to do
- Deploying to other environments
Project 6: Website Analyzer

Make a scraper that analyzes the semantics of websites and create a ranking for them. For example, you could check for missing alt tags on images and check if SEO meta tags are on the page. You could even implement the scraper without creating a UI.

What you will learn:
- The workings of a scraper
- Making DOM selectors
- Writing an algorithm
- Go the extra mile by creating a UI and make a report of every website that you crawled
Project 7: Mining Social-Media Sentiment

source（https://www.csc2.ncsu.edu/faculty/healey/tweet_viz/）

Mining social-media sentiment is a great way to learn something about machine learning.

You could start off by just mining one social-media platform, with Twitter being the classic entry point.

Developers that have more experience with machine learning could try to mine different social-media platforms and than combine that data.

What you will learn:
- You will get a grasp of machine learning
Conclusion
These projects should keep you busy for quite some time. Just pick a project, and go for it. I am looking forward to seeing the results of your project.

Happy coding!
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第562期：《战斗力不到5 genpAss》

28 9 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《战斗力不到5 genpAss》
今日推荐英文原文：《Demeter’s Law: Don’t talk to strangers!》

今日推荐开源项目：《战斗力不到5 genpAss》传送门：GitHub链接
推荐理由：密码密码，顾名思义自然是不能让别人轻易知道的……这个项目是一个弱口令生成器，会根据提供的个人信息生成弱口令，简直就是完美的反面教材。如果你的密码能被别人像这样猜到，那实在是太过于尴尬了。就算是怕忘记，也有个最简单的办法：找一本英文书，选一页，把最左边的字符作为你的密码，只要你的书还没丢，就能一举两得——既不会被简单破解，也不会轻易忘记，何乐而不为呢？
今日推荐英文原文：《Demeter’s Law: Don’t talk to strangers!》作者：Carlos Caballero
原文链接：https://medium.com/better-programming/demeters-law-don-t-talk-to-strangers-87bb4af11694
推荐理由：虽然难以置信，但是老早以前的这条法规在写代码上一样适用
Demeter’s Law: Don’t talk to strangers!

Software Engineering Principles

The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs.— Wikipedia
This law was proposed by Ian Holland in 1987. Holland and colleagues were programming a system called Demeter using oriented object programming. During the development of the system, they realized that the code that fulfilled a series of rules was less coupled.

Demeter’s law is known as “don’t talk to strangers” because:
- Each unit should have only limited knowledge about other units — only units “closely” related to the current unit.
- Each unit should only talk to its friends — don’t talk to strangers.
- Only talk to your immediate friends.
More formally, the Law of Demeter requires that a method m of an object O may only invoke the methods of the following kinds of objects:
- O itself.
- m’s parameters.
- Any objects created/instantiated within m.
- O’s direct component objects.
- A global variable, accessible by O, in the scope of m.
In summary, all of the rules above can be summarized by saying you should avoid invoking methods of a member object returned by another method. In modern object-oriented languages the identifier used is dot or ->. Therefore Demeter’s law is violated when the code has more than one step between classes. For example, the following code shows an example in which Demeter’s law is violated:

In this case, an object a from the A class can request a method of an object instanced of B class but the object A should not reach object B directly, because that would mean the object A has greater knowledge of object B’s internal structure (tight coupling).

The following image illustrates who are friends between class relations:

Real example — Person → House → Address
Now, I am going to show a real example implemented with TypeScript. In the following UML diagram you can see as a Person is related to House and House is related to Address.

The original code is from https://github.com/tavaresasilva/LoDRaV, coded using JAVA.

The following code can be run in the client/context, whereas the first code broke Demeter’s Law due to Person requiring knowledge about the inner implementation of the class House. On the other hand, the second implementation respects Demeter’s Law and the code is less coupled.

The following steps show you must implement the code to respect Demeter’s Law and obtain a less coupled code. So, the first step is to create the interface which will be implemented in our concrete classes:

The next step will be the implementation of the concrete classes as you can see below:

The most important thing in the code is that no method violated Demeter’s Law (there are not more than two consecutive invocations of contained objects).

Here’s another example in which the Demeter’s Law is broken:

In this case, the solution is to implement isZipCode method in class person, as you can see in the following code:

Advantages
The main advantages of satisfying Demeter’s Law are:
- Dependencies between classes and coupling are reduced.
- Classes can be reused with ease.
- The code is easier to test.
- The code is more maintainable and flexible to changes.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第561期：《读史使人明智 tongjian》

27 9 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《读史使人明智 tongjian》
今日推荐英文原文：《How To Stand Out During Your Stand Up》

今日推荐开源项目：《读史使人明智 tongjian》传送门：GitHub链接
推荐理由：这次要推荐的项目是资治通鉴……当然了，肯定不是全文，而是一位希望能够快速阅读的作者制作的精简版，将全文分割成许多片来一片片阅读，通过为每一片古文添加注释等来降低阅读门槛。通过阅读可以丰富自身的内涵，不管是科幻小说还是古典文学都在阅读的范畴之内，资治通鉴当然也在其中。如果你对这长长的古文感兴趣的话，也可以为这项目作出一份贡献。
今日推荐英文原文：《How To Stand Out During Your Stand Up》作者：Michael Henderson
原文链接：https://medium.com/@michaelhenderson/how-to-stand-out-during-your-stand-up-33caeb600ee2
推荐理由：如何在会议中让自己变的更有用
How To Stand Out During Your Stand Up

don’t be like every other pea in the pod

Image Courtesy of Magniscan on Pixabay

For some dev teams, a morning standup is the only time that you get to interact with your team members outside of instant messaging or email. So, it is important to be detailed, engaged, and interested in the goal that your team is trying to achieve. Not only are those qualities part of being a good developer but they can help pull your team across the finish line when they need it most. I am sure you have heard the saying that one bad apple will spoil the whole bunch… well, the opposite is also true. If you are positive, engaged, and interested in what the team is building then that attitude will most likely be reciprocated throughout other team members.
Be Detailed
Other team members must be picking up what you are putting down. For example, if you are going to talk about a bug that you fixed, don’t be one of those devs that say “yesterday I fixed a bug”. My friend, you are a developer who is most likely making good money, you can do better than that. Here is a good example of the lousy example above:

yesterday I worked on bug number 2490 and was able to finish it up before lunch. I ran into some issues but Ashley was able to explain a few things to finish up the task. After that, I moved on to task 5501 which is the label change in the navigation menu. I will be working on that for most of the morning.

See, not only does that sound better but it is informative to the entire team. You never know what problems you solved by being detailed. There have been times in my standups where the bug I was working on naturally solved an issue that another dev was going to begin working on that day.
Code Blockers
Although we hate to admit it, especially if we have wasted a lot of time on trying to fix a particular issue, but blockers are important to bring up to the other team members during the standup. To go ahead and address the wasted time reference, don’t let yourself be stuck on a particular coding problem for more than 30 minutes. Reach out to a team member, send a chat, or shoot a detailed email after you have researched and tried to solve the problem yourself. Anyway, yea, blockers suck.

There are two main reason why you should mention your blockers during standup.
- Other team members could have a quick and easy solution to solving the problem that you are stuck on. Better yet, they may have solved the same problem before and can walk you through the process.
- It lets the leads and other developers know where you are in the development process. If you mention a blocker during the morning standup then you and another dev spend half the day trying to fix it, your time is justified and accounted for. If you spend a week trying to get past a blocker and don’t tell anyone until it is too late, then you are seen as underperforming.
Yup, I know how it is. You think to yourself “just 5 more minutes and I will have this problem solved” well, that is not always the case. As much as us competitive developers hate to ask for help we just need to do it for the sake of finishing a product and for the sake of learning from other developers. If you never ask questions then how will you learn?
“The man who asks a question is a fool for a minute, the man who does not ask is a fool for life.” — Confucius

Reference Pull Requests and Bug Numbers
Did you leave detailed comments and information on bugs or pull request that would be worth mentioning?

Maybe you asked the lead developer during standup to review one of your pull request. If there is another pull request that needs to go in before that one or if there is an issue that needs to be resolved before your pull request is fully finished, then mention it. Give the numbers, send a link after you are done with the standup.

All of this is to make the other team members job easier. After all, we want to work together to make all of our lives easier, productive, and efficient. If that is not the goal then why do we spend time setting up pipelines and implementing CI/CD?
Be Interested

Image Courtesy of kaboompics on Pixabay

Being interested in the project you are working on is one of the motivational factors that will lead you to put effort into your work and doing the best you can. A lot of people are ok with coming to work, not doing much, and getting a paycheck… but what quality of life will that provide you?
Suggest Improvements
Be excited about what your team is building! Are there improvements that you would like to suggest? Maybe certain components are being built that could be built better. Maybe the team members should start linting their code before opening a pull request so the code is more efficient and the build time is quicker. Maybe you should suggest a style guide for building maintainable code… after all, if code is clean, optimized and secure, then the results of the end product will follow. Even if the rest of your team is lazy and disengaged, don’t be afraid to stand out.
“Better to embrace the discomfort of being different than the comfort of fitting in.”― Ogwo David Emenike

Team Goals
What goals are most important to your team at the moment? Maybe the lead needs a certain piece of functionality for the web application to be complete for a demo that is going down this Friday.

Be sure to understand the goals so that you are making progress and meeting expectations. I have seen it a thousand times where a developer simply just won’t ask because they are afraid it will cause them more work or they will actually have to do something for a change. Don’t be that type of developer, that will get you nowhere in life and your career.
Lend a Helping Hand
If another dev on the team mentions that they are working on a certain bug and you have some experience in that area of the application, then speak up! Let them know to ping you in Slack or send you an email if they have any questions. This is especially important if it is a new dev. You want them to know that every person on the team is not in it for themselves. You are a team so you work together to pull everyone across the finish line.
Be Engaged

Image Courtesy of FreePhotos on Pixabay

Honestly, being engaged is one of the traits that a lot of successful developers have. A developer can be faced with a problem and no matter how big, they will engage with the problem, ask themselves questions, and ultimately come to a solution. Then, when coming to a solution they engage in the solution to make it better, faster, and stronger. I am not asking you to build a solution or solve a problem right now, I am simply asking you to be more engaged during your stand up.
Set the Tone
This can be hard if your team has standups early in the morning. Don’t let it sound like you lost your best friend and then the coffee you drank induced explosive diarrhea. During standups, set an uplifting, and ambitions vibe when engaging in the conversation at hand. Even if there is a problem or you ran into a blocker, sound optimistic about it. If you are setting a bad tone during a standup, especially a morning standup, then the day is most likely going to be bad.
Speak Up
If you do your standup through voice communication and not physically in a meeting room, then make yourself announced when you join the call. For example, when I call into the standups for my team, I say “Good morning, Michael is here”. It sounds weird but it lets others on the call that may have joined earlier know that it is me on the call and not a ghost.

If you notice that someone new is on the call, maybe they just joined the team, then introduce yourself. Let them know what you do on the team and let them know that if they have any questions then they can feel free to reach out to you.

I have personally made it a goal of mine to be more engaged this year and it has changed the way I perform when slinging code, receiving constructive criticism and having a conversation with a teammate. You see, being engaged is about listening, understanding, and helping others. A quick note about helping others… don’t do it during the standup.

A lot of times developers have questions during standups or have a blocker that they are dealing with and need your help. Instead of solving the issue during the standup while other people are waiting, ask them to shoot you a message. This makes sense because standups are not the place to solve issues and problems that have occurred nor is it a place to waste other peoples time. The same goes if you are needing help from another dev. Don’t expect someone to help you during standup, if another dev is willing to help you and wants you to contact them after, be sure to follow up.
Conclusion
If you do what was mentioned in the other parts of this writing then standing out will come naturally to you. If a company sees that you are not interested and are not fired up about what your team is building then that mood and thought process will eventually show in the finished product.

Be the best you can be and don’t be afraid to stand out. People that standout work for some of the best companies. The only reason those companies are the best is because the people that work for them want to stand out, they want their team to stand out, and they want the company they work for to stand out.

How can I be more engaged, interested, and detailed with my work? I ask myself that question at least once a week. It is good practice because it has helped me stand out, not only during standups but with any type of product that my hands touch.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第560期：《色号召来 chinese-colors》

26 9 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《色号召来 chinese-colors》
今日推荐英文原文：《Write Better Quality Software Without Deadlines》

今日推荐开源项目：《色号召来 chinese-colors》传送门：GitHub链接
推荐理由：在成千上万种颜色中选出一个刚好合适的总是不太容易。这个项目收录了一些中国传统颜色的具体属性，包括 CMYK 的印刷四色模式和 RGB 三原色模式，作为平时的备忘录使用刚刚好。而且每种颜色都附赠了一句古典诗词，更突显了整个页面的文化气氛，这个细节着实是令人眼前一亮。

今日推荐英文原文：《Write Better Quality Software Without Deadlines》作者：Jamie Morris
原文链接：https://medium.com/swlh/write-better-quality-software-without-deadlines-4526dc3edc19
推荐理由：一种不同的看法：应当保证产品的质量，哪怕拖延一些时间
Write Better Quality Software Without Deadlines
How would you write software if you had all the time in the world? Would you do anything differently to what you do now? This is a question asked in Extreme Programming.

You must have heard of the project management triangle, right? Make a triangle and on each point you have some variation of the following: cost, time, scope. You can only control two of the three. In the centre of the triangle is a dot, and as it moves towards any corner it must then move further from the others. It is a useful concept, but there is something missing.

What about quality? Let’s abandon the triangle and imagine instead a series of dials that control each facet. As the client, and the person paying the bills, you turn scope up to 10, signalling that getting all of the features is the most important consideration. But by doing so the cost, and time dials are also set to 0. They will be sacrificed on the altar of scope. So you dial up time a little, because you need all of the features by Christmas. Doing so will turn down the quality dial, because the only way to deliver the features asked for is to accept technical debt and skip things like testing, refactoring and peer reviews.

This is pretty typical. Quality is usually the most flexible element in the eyes of both developers and stakeholders, even if they don’t admit it. I’ve heard numerous teams say things like “I want to write tests but I don’t have time” or “we’ll refactor after the next release”. Sometimes this is necessary — there is a missed opportunity cost to delivering late, no matter how beautiful your architecture. Sometimes you simply don’t have the money to hire 30 expert developers, so you make do with what you have.

But I had the privilege once to work at a company where quality was paramount. So much so that despite a team of 40 developers and 5 years of software in production, they only ever had two people working on support, and those 2 people changed every week. When my turn came, I continued with my day job and dealt with a total of two simple support tickets during the week. I have worked at much smaller companies with dedicated teams of support staff who were raking leaves in a hurricane. The quality in this team came from their strict adherence to Extreme Programming and to something they called the golden rule.
The development team are not allowed to know any deadlines
They didn’t invent the concept, but it was the first place I saw it work, because everyone believed in it. The only person who knew the deadline was the Product Owner, and they had the integrity, conviction and authority to stick to the golden rule.

So why do I think it was important? Take this conversation:
- Boss: “How long will this feature take to deliver?”
- You: “A week.”
- Boss: “Not good enough!”
- You: “Ok, a day.”
What changed? Were you lying the first time? Did your boss inspire you to write more code in less time? You probably adjusted your estimate to make it more palatable. We’ve all done it and regretted it later.

I see the same happening with immature scrum teams all the time: you impose these artificial deadlines where every two weeks you end up rushing to get things done. With a little smoke and mirrors you get the user story through the sprint review without the tests or with some hard coded data. Whatever you need to get sign off. This is bad, because now you’re starting the next sprint on the back foot. You just told the Product Owner that Story A is complete, according to whatever your definition of done is. Presumably your definition of done does not say “it looks finished to the casual observer”. So in the next sprint when the Product Owner thinks you’re working on Story B, you’re actually still finishing what you didn’t get done in Story A. Or worse, you cut your losses and move on, accepting that technical debt is something that gets paid by other people.

So let’s assume we are going to deliver late and want to try and fix it. What are the things we think we can control?
- The first is scope. Well, this is the obvious one to cut, but as it happens, the team I worked in was already very good at figuring out what the Minimum Viable Product was for any given story, so the scope was already about as thin as it could get. Sure, the Product Owner may have the clout to trim it down even more, but most of the time that wasn’t the case. For those of you not blessed with supreme harmony between stakeholders, Product Owners and developers, scope is absolutely the first thing you should consider cutting if a deadline can’t be met on time.
- Next is cost, which usually means resource (I hate the term resources because developers are not fungible, but let’s go with it). One proposed solution is to work overtime. One of the core tenets of XP is that if your team has to work overtime two weeks in a row, something is broken and needs to be fixed. Don’t use overtime except in emergencies, because you will burn out your team. The other proposed solution is usually to hire more developers. That might work in the long term, but it takes time for even the most experience developer to become acquainted with the project. Hiring more developers is a long term fix for a short term problem. It won’t help you deliver faster now. And sometimes it won’t even help in the long term. Remember that nine women can’t make a baby in one month.
- The last thing we can sacrifice is quality. In other words, we can cut corners. You might skip peer reviews or disable some failing tests for now because they need to be rewritten. You build up technical debt, buying time from tomorrow to pay for today’s problems.
At the company I worked for, sacrificing quality was not an option in almost every case. Where quality had to be sacrificed it was temporary, with a firm commitment to pay it back later. Although come to think of it, I can’t think of a single time I saw them resort to this.

So by eliminating scope, cost and quality as mutable values, the only conclusion is that time cannot be of paramount importance. It isn’t necessarily the least important, since by adhering to the MVP, scope is already being sacrificed to facilitate quick delivery. But it is less important than quality, and dialling up the cost won’t make an appreciable impact until it is too late.

So don’t give developers the temptation to cut corners. Remove the deadline from view and let them make the right choices to deliver high quality software. This will pay dividends in the long term by reducing the cost of a dedicated support team, and often allows for faster delivery by writing code that is easy to work with.

I’d like to pose a challenge to those of you who think this couldn’t happen in your team. Explain the concept to your stakeholders. Be sure to explain the concept of a Minimum Viable Product (which I will blog about separately). Ask them to rank the four variables in order of importance. I hope they give you something like this:
- High Quality
- Quick Delivery
- Low Cost
- Broad Scope
Hold them to account, and make sure your Product Owner does so, too. You might be surprised at how much this kind of thinking resonates with the people paying the bills.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/