开源日报 - Page 176 of 262

2019年2月19日：开源日报第341期

19 2 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《方便的练级手段 vscode-leetcode》
今日推荐英文原文：《Moneyball and Software Development》

今日推荐开源项目：《方便的练级手段 vscode-leetcode》传送门：GitHub链接
推荐理由：LeetCode 这个刷题的地方相信或多或少大家都有所耳闻了，打开一个题目，然后对着编辑器摆弄解法，然后写好之后解法填上去测试结果。这个项目把这个步骤简化了一下，只需要在 VSCode 中你就可以完成登录解题等一系列步骤而不需要开个浏览器，趁此机会刷点题练习一下自己的算法知识是个不错的主意。
今日推荐英文原文：《Moneyball and Software Development》作者：Todd Moses
原文链接：https://medium.com/todd-moses/moneyball-and-software-development-83c884235765
推荐理由：在不完美的情况下如何做出最好的产品
Moneyball and Software Development
In a perfect world one has the right team, enough budget, and a realistic timeframe. However, this usually never happens. Software Managers are given team members based on availability, budgets are pre-set and timeframes are rushed. The problem becomes, how does one deliver a quality product within these limitations?

Billy Beane, the Baseball Executive for the Oakland Athletics, had similar stipulations for his team. The result was, “Moneyball”. A statistical approach to determining what positions on the team required the best players. In other words, given a smaller budget than needed to compete in Major League Baseball, what is the best way to spend it?

The results went against the traditional approach, making the playoffs on a shoestring budget. Concluding with a book by Michael Lewis and later movie of the same name. While powerful for sports management, this team building strategy has many applications in other fields. Including software teams.

Software Leaders have similar issues to Baseball Managers. That is to pay for proven talent at a premium or take a chance on young, unproven developers at much less cost. While the large companies can and do hire the big names (in baseball and software), smaller organizations often have to settle for less. That is, until they determine the positions key to the teams success. In other words, what are the most valuable attributes for their company?
Measuring Limitation
Every person and by default team, has limitations. In software, this means areas of inexperience where actual ability does not match the current requirements. Often, these limitations are subtle. Becoming apparent in the middle of a project plagued by trouble.

Consider a Developer well versed in building database applications. He or she has proven themselves on many difficult projects. They work well with a Front-End Developer who truly understands modern web development with a few high profile websites in their portfolio. Assisting the two is a Database Administrator who uses best practices to build required schemas and an Architect with both development and business experience.

While this team appears solid, there are limitations that could derail a seemingly simple project. The reason is that this team, like most, are very good at a subset of technology, but could become lost if pressed to adopt new ones. Usually, this occurs when a new Architecture Pattern is needed, a change in Framework, or something else that requires a learning curve.

For example, the software team at a small hedge fund was very good at writing financial trading systems using the mature data feeds available for stocks and option pricing. However, when Cryptocurrency trading facilitates were needed to be included into several strategies, the team was a loss. Perhaps the worst part was no one admitted they were unable to quickly implement the new strategy. Instead, the team acted as if it was just another data feed to digest. Fast forward a month later, and the entire project had failed.

At other times, it may be a skills deficit within the team. For example, a new Computer Science Graduate may have only been exposed to a few of the technologies required in his or her new position. If one assumes their abilities are the same as a developer with several years of professional experience, it will cause problems. To make matters worse, many new developers will not clearly state they are unable to do something.

During a Sprint Planning Meeting, it was asked of the team if they felt comfortable with the work assigned for the next two weeks. The answer was “Yes” by all involved. When pressed with, “You are certain that the entire body of work can be completed within the next two weeks?”, the answers started to change. The reason was they were given an out by management. An open channel of communication to admit that the demands were unreasonable.

It is important to understand the Team’s weakness. The area or areas where the team is incapable of delivering at a high level. It can be discovered through trusted communication or testing. Some examples of team weakness include: single stack competency, lack of math skills, inability to code outside of a specific framework, and/or an unrealistic view of their own abilities.

Even the best teams can commit to more than they are capable. Developers by their very nature love challenges and will quickly want to tackle hard problems. For this reason, it is important to have a retrospective after each development cycle. A time where the team can explain the problems, solutions, and changes required to improve. When done correctly, this will lead to a better understanding of the team.
Overcoming Budget
Since every team has areas of weakness, where do the strongest members need to be. To put it another way, what roles are your best developers fulfilling? Is it a strong back-end presence or an excellent DevOps Engineer? Perhaps a Front-end Developer who thinks in JavaScript is the most important. Chances are, not every position on the team needs an expert. Some of the roles could get by with a minimum level of competence.

Billy Beane discovered that the most valuable statistic in a Baseball Player was on-base percentage. That is the ability for a batter to make it to a base by any means possible. In Software Teams, there is also a most important statistic. The key is to discover that for your organization.

Unless you have a large budget to hire the best like the New York Yankees, some important calculations need to be done. Beyond a general competency, there are a few key attributes of team members that are more important than all others.

For example, a team dealing with large scale data may need people with a very high aptitude for statistics. A corporate team building Line-Of-Business Software may need people with solid business understanding. The point is that hiring for specific abilities beyond the job requirements will improve the team without increasing the budget.

A Defense Contractor discovered that Software Developers with advance degrees in Physics and Mathematics were much more capable in building missile guidance software than those with a Computer Science background. In a manufacturing company, they found adding developers with a degree in Mechanical Engineering vastly improved the team. Likewise, a corporate team hired developers from a respected coding camp with backgrounds in Accounting and Finance.

Billy Beane was hiring beyond basic competency since every member hired came from Professional Baseball. Meaning. they had an expertise in the required field. It was only after they made the cut to be in the Major League that the other attribute was applied. Thus, managers need to hire competent developers with the chosen attribute(s). Not the other way around.

Another important fact with Moneyball is that Billy Beane let go of many team members to build his roster. Thus, an important first step after discovering the attribute(s) most needed is to remove those team members that do not possess it or who have expertise outside of what is required. For example, Beane discovered that a highly talented First Base Player was not needed. So he removed the cost by replacing the position with a low salary player.

Not everyone on your team needs to be an expert. A general level of competence is all that is needed for many positions. However, it is a best practice to remove team members that do not possess the core competence of software development. That is, have a minimum level of ability that must be met by everyone and specific expert requirements where it matters most.

With that said, some team members are teachable and can quickly get to the level of competency needed. Others may not. It appears there are Career Developers who love what they do and have the desire to constantly improve. Then there are Job Developers that only care about learning enough to keep their paycheck. Those should be eliminated from the team.
Expanding Efficiency
Once a group is in-place that has the core competence and the magic attribute(s), there is still much work to be done. Ask any professional sports manager who has maxed their budget with talented players yet still suffers defeat. The point is that besides hiring great people, one has to build a team.

This team needs to succeed or fail as a single unit, not as individuals. Accountability is placed on the group and not on any one person. When someone is not doing their job effectively, the group will quickly make adjustments. That is to say, problem individuals will not last long inside a solid team. The team will either help them reach the required level of performance or push them out.

Another aspect is culture fit. Each member of the team must subscribe to the culture. Be it a love for the subject matter, belief in the goals of the company, a desire to build something great, or something else. Yet, every member of the team must be dedicated to the achievement of some objective outside of just completing their work.

In some startups, the common goal is building something worthwhile. At large companies, it is making something noteworthy for their department. Financial developers often measure their success in terms of profitability. The point is that every great team has a goal. A great leader helps guide them to achieve it.
Conclusion
While it is difficult for a Development Manager to build a solid team on a limited budget, it is not impossible. Making strategic decisions on what positions to fill with high levels of expertise and which to settle for a minimum competency is hard. However, the hardest part is building a cohesive unit dedicated to the achievement of a common goal.

Discover where you need to spend the money for top talent and then fill the other roles with dedicated employees eager and able to assist them. Take the time to listen to the team and build a culture of goal accomplishment over meeting deadlines.

A disturbing trend in software teams is the modern carpentry approach of work fast and take many shortcuts to accomplish the most in the shortest time frame. Then rely upon someone else to find the issues, often at a much later date.

In contrast, a team dedicated to goal achievement may not accomplish as much as a team dedicated to rapid development. However, the end result will be greater. It may take an extra week to complete a release. That is not always a bad thing. A great team will set its own pace based upon quality of work. Great management listens and gives them the time needed to make something worthwhile.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年2月18日：开源日报第340期

18 2 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《函数式编程 awesome-functional-programming》
今日推荐英文原文：《Debug Framework》

今日推荐开源项目：《函数式编程 awesome-functional-programming》传送门：GitHub链接
推荐理由：相信不少人都已经听说过函数式编程了，它是一种结构化编程，主要的思想是把一个程序尽可能使用一系列函数调用来完成，这个项目就是一个关于函数式编程资料的集合，包括一些博客文章，论文和视频等等。不管是对于函数式编程已经有了一些了解还是尚未学习但是感兴趣的人来说这个项目都能帮上他们的忙。
今日推荐英文原文：《Debug Framework》作者：Matt Mcnamee
原文链接：https://medium.com/pvtl/debug-framework-1a0c0586af9e
推荐理由：在解决你面对的问题时你可能用得上的一种思路
Debug Framework
Over the past week I’ve been in two situations which have encouraged me to think about the way I ‘debug’ or problem solve.

After reflection, I thought I’d share an unconscious framework I seem to follow, whether it be for solving problems in life or in code. Having a simple pattern to follow may empower you to solve problems in a more timely manner with less anxiety.

Hold onto the following two scenarios as we explore further:
1. In my band, a friend plugged his bass guitar into the amp. It buzzed for a couple of seconds, went silent and when he tried playing the bass — the amp remained silent. After several seconds of tapping and twisting different things, he frustratedly remarked — ‘This amp has shit itself, it’s completely busted…we need to get a new amp’
2. At work, a colleague (web developer) was tasked with fixing an issue where styles weren’t appearing as they should. Almost two hours after starting the investigation, disheartened that he hadn’t progressed, reaches out for assistance.
We’ll explore the the following pattern which is iterative, so we’ll repeat over and over until we get to the root cause and then solution:
1. Frame
2. Identify
3. Reduce
01.FRAME accurately
Before you go any further, it’s really helpful to frame the issue accurately. For example:
Bass Guitar example
- The overall problem wasn’t that the ‘amp is busted’. The problem was that ‘we’re not hearing the amplified sound of the bass guitar’.
Website example
- The overall problem wasn’t that ‘the production site just broke randomly’. The problem was that ‘in Safari on iOS the checkout page is missing all elements’.
Why frame the problem like this? Framing the overall problem avoids assumptions. Notice in the bass guitar example, that the friend immediately assumed that the amp was the problem and therefore was fixated on ‘fixing the amp’ (ignore all other possibilities)?
02.IDENTIFY possible causes
In most cases, there could be a number of things causing the problem, or even a specific combination of one or more things. It’s helpful to identify each of these broader pieces. For example:

Bass Guitar example — the relevant parts that could cause the issue may be:
- Bass Guitar
- Guitar Lead (from guitar to pedal)
- Pedal
- Guitar Lead (from pedal to amp)
- Amp
- Power
Website example — the relevant parts could be:
- Web browser (eg. application bug, cache)
- Internet connection
- Web server
- Continuous deployment tools
- Website code (Git tracked code that we’ve written)
- Website state (database, any files that store data, non-Git tracked files (eg. dependencies, plugin))
Notice that for now, we’ve identified the broader pieces like ‘Bass Guitar’. Right now, it’s not yet helpful to further break the bass guitar into small pieces (eg. strings, pick ups, knobs, wiring etc). Remember, this process is cyclical, so in the next loop, we may need to identify the pieces of the bass (if we find that the bass guitar is relevant to the issue).
03.REDUCE the surface area
Now that we’ve identified each of the pieces, we need to focus on testing and eliminating each piece one-by-one until we find the piece that’s broken. We can be tempted to lazily “scatter-shoot” our attention across all pieces at once; however we must procedurally isolate and test one piece at a time to prove that it is or isn’t a suspect in this problem.

Isolating might mean swapping out whole parts or disabling whole features to determine if that piece has an effect on the issue.

Let’s go back to our examples:
Bass Guitar example
- The bass guitarist could plug the guitar straight into the amp with one of the leads. This eliminates the pedal and the other lead. Rather than troubleshooting all 5 parts they’re now only focusing on 3 parts. When we did this, it turns out music still isn’t coming out of the speaker, so we started swapping those 3 parts with other parts, and continued isolating.
- After swapping one lead with the other lead, glorious music is sounding from the amp!
Great so the problem was the first lead (not the amp)!

If we’re interested in digging further into why the first lead doesn’t work, we could repeat the process with the smaller problem — Frame the problem as ‘the lead isn’t transmitting a signal’, identify the pieces as 2 plugs and wires and reduce the pieces one-by-one.
Website example
- It turns out the website was working a week ago, but there weren’t any code changes since then. So we can eliminate “website code” as a possibility.
- Does it work in any other server environments (ie. local computer or staging server)? What do you know, we found that the error didn’t happen on the staging server.
- What are the differences between staging and live? There’s a ‘social sharing’ plugin which was active on live, but not in staging. What’s more, when we activated the social sharing plugin on staging, that environment had the same error.
Ok good news. We know that the the Social Sharing plugin is causing this issue. We can continue by repeating this process, focusing on the Social Sharing plugin:
- Frame the problem as ‘when enabled, the Social Sharing plugin is causing elements not to display in Safari in the checkout’
- Identify the pieces as CSS styles it’s injecting, JS it injects, HTML layout it manipulates
- Reduce the surface area by eliminating each piece one-by-one
We may then find that it’s some CSS, and therefore need to repeat the process within the CSS. As they say, rinse and repeat.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年2月17日：开源日报第339期

17 2 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《自动上色流 style2paints》
今日推荐英文原文：《What We Have Here Is Failure to Communicate》

今日推荐开源项目：《自动上色流 style2paints》传送门：GitHub链接
推荐理由：这个项目是一个 AI 上色系统——把你给的线稿上色，而且看起来意外的还挺像样，你只需要稍微修改一点点觉得不太好的地方收尾即可。唯一的缺点是，因为没钱他们已经把使用功能给停了开始弄下个版本，兴许以后可以期待一下离线版本之类的，如果感兴趣的话也可以提供些赞助。
在线观摩演示视频：https://www.youtube.com/watch?v=B6WEky9nY7Q&feature=youtu.be
今日推荐英文原文：《What We Have Here Is Failure to Communicate》作者：Tomer Dicturel
原文链接：https://medium.com/@dicturel/what-weve-got-here-is-failure-to-communicate-13f80189aced
推荐理由：高效的沟通带来高效的工作，如果不能面对面沟通（这个相当方便，比聊天软件快的多），最起码也该使用聊天软件
What We Have Here Is Failure to Communicate
Communication is vital at every level of a software development project, but you’d be surprised at just how often this fundamental rule is broken. And when there’s no communication, that’s when the final product created can look very different from what was sold, promised, built and ordered.

How the customer explained it.

If you’ve ever seen the cartoon called “Tree Swing,” you’ll know exactly what I’m talking about. The cartoon consists of 10 different images, each one showing a different version of a “tree swing.” As you might have guessed, there’s something very wrong with each and every one of these tree swings. The first image is very innocently captioned, “How the customer explained it.” Instead of showing the sort of iconic tree swing that we enjoyed in our carefree youth, it shows what looks like three different swings combined into one, all hanging from the same tree.

And each image gets progressively more absurd from there. For example, by the time the sales executive has described the project, the tree swing now includes a massive blue armchair suspended from the tree. The final image is the most telling — it shows a humble car tire hanging from the tree instead of a swing, with the simple caption, “What the customer really needed.”

There is perhaps no better visual that can convey why a failure to communicate can be so harmful for a software development project. It doesn’t take a rocket scientist to realize that building a better mousetrap (and a better tree swing) is going to require plenty of communication, at several different levels.

First of all, there needs to be communication at the team level. All developers on the team need to be on the same page. Moreover, each one of these team members needs to commit to regular communication, especially as new issues arise. It’s great to schedule a Monday morning check-in call every week, but if a question pops up on a Thursday, then there needs to be a process in place for team members to meet before Monday.

by Scott Adams

And, secondly, there needs to be communication between teams. Typically, it is the role of the project manager to convey all issues and problems with external stakeholders. This is easier said than done, however, because it often requires a simultaneous translation between the strange foreign language spoken by software developers and the even stranger foreign language spoken by MBAs and senior executives. That’s why simple tree swings often transform into overstuffed blue armchairs suspended from trees — the sales and marketing team may be so eager to sell a new product that they ignore what’s actually feasible or practical.

If you’re looking to keep your software development project on schedule and on budget, then make sure you’ve opened up all lines of communication with your team members and empowered them to talk about issues in real-time. Otherwise, you could wind up like the Paul Newman character in the classic Hollywood film “Cool Hand Luke,” rolling around in the dust, and your manager standing over you while repeating the famous line, “What we’ve got here is failure to communicate.”
Failing To Plan Is Planning To Fail
It’s always surprising how many software development projects launch without a real plan to complete them. Of course, there may be some hazy estimates thrown out during meetings, like “try to get this done by the end of the quarter,” but what I’m talking about here are real, actual plans with dates, deadlines and milestones. In short, what needs to happen (and in what order) for a project to be completed on time and on budget?

Of course, it almost goes without saying that any plan is bound to encounter its fair share of delays, revision and re-thinks. In the world of software development, that’s par for the course. Clients will inevitably call at the 11th hour, requesting a change or revision that might set back your project days, if not weeks. And emergency “fire drills” happening in one part of the company might siphon away critical resources, including valuable manpower.

But here’s the thing: a plan for your software development project gives valuable structure to your team. It enables team members to provide estimates about when a certain leg of the project is going to be complete, so that when the VP of Operations is giving you a call, demanding to know when the project is going to finally be ready, you’re ready with a response.

by Scott Adams

This insight into how long a project is going to take and how much it is going to cost is especially important for large software development teams, simply because there are more people to keep in the loop. More moving pieces = more complexity. And, don’t forget, you might be working with developers based offshore or in a different city, and that is going to add in even more variability and uncertainty to the process. So a master plan is one way of keeping everyone in the loop.

When estimates for a plan change, it will have a very significant impact on the overall budget. Simply going a few weeks over schedule might cost the company tens of thousands of dollars. As a result, you have to make sure the estimates being used for the plan from the very beginning are actually reasonable.

It’s not reasonable, for example, to expect that a major app project is going to be complete in just one week. And it’s also not reasonable to expect that a software development team is going to be able to complete a project if it is constantly encountering resistance from upper management or not getting access to the right resources to get a project done. Oh, and it also doesn’t help if a key member of the team suddenly quits, or if corporate HQ calls and tells you that funding for the project has been slashed because of an upcoming merger or acquisition.

Ultimately, there is a very important link between getting a project done on time and getting a project done within established budget parameters. The link, of course, is the plan. At the end of the day, failing to plan is planning to fail.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年2月16日：开源日报第338期

16 2 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《教程 intro.js》
今日推荐英文原文：《So What Does This Button Do?》

今日推荐开源项目：《教程 intro.js》传送门：GitHub链接
推荐理由：在你的个人网页上搞了个新玩意？或者是学校的论坛上增添了新功能？这个时候就是这个项目出场的机会了，这个 JS 库能够帮助你简单的弄出一个教程指引，就像你在各种网游上看到的那样——高亮一个区域，然后写上任何你想写的，重复前两步。最起码，总比在页面的某处放上教程来的方便友好些不是吗？

今日推荐英文原文：《So What Does This Button Do?》作者：Tomer Dicturel
原文链接：https://hackernoon.com/so-what-does-this-button-do-a47b6a17c66c
推荐理由：如果没有技术文档，谁也不知道你之前写的这个按钮究竟是干啥用的（可能你自己也……）
So What Does This Button Do?
In the world of software development, it’s important to be agile and move fast. However, technical documentation is also important. Document, document, document. Without documented code, you might be facing years of technical debt, as people try to figure out what different buttons do, and what functionality is really present in the software that you have just created.

Here’s an intuitive, real-world example of why project documentation is so important: take a look at the remote control for your living room TV set. Do you really recognize half of the buttons on the remote? Do you know how to use them? (Even the button at the very bottom that has some symbol on it that looks like it’s from an ancient language?) Yet, all of those buttons, no matter how obscure, were considered a “good idea” at some point of the design process. Most likely, these “features” were actually a “bug” that nobody bothered to figure out. As long as everything worked at the end, it was probably safer just to ignore the buttons that seem to do absolutely nothing.

That same sort of confusing functionality is also part of many failed software projects. Nobody really knows what certain buttons do, or why they were even included in the original design. Maybe a developer decided to add a test feature after receiving a panicked email message from the CEO, but never remembered to remove it later.

So what type of documentation should you include for a software project? The current best practice is to document every step of the development process, from ideation to design to execution. And this documentation should be easily navigable for others, not just filled with a lot of cryptic, insider notes that are impossible to decipher.

Of course, the common complaint from developers is that too much documentation is going to slow them down. If they are in a sprint, do they really want to slow down and take the time to add a few notes about what a line or two of code does? Of course not. Time constraints are a very real feature of software development projects, so it’s easy to see why there can be some internal resistance about documentation and tracking.

But here’s the thing — as much time as you might spend moving forward, you are going to waste more time going backwards. In other words, the whole testing and de-bugging process is going to be a lot smoother and easier to navigate if the right documentation is in place. When you are de-bugging software, you absolutely need to know how things work, and the internal logic of each new piece of functionality. That’s especially true for large-scale software projects, where searching for what just went wrong can sometimes feel like searching for a needle in a haystack.

You can think of technical documentation as tiny breadcrumbs that you leave along the way for others. People following behind you will have a trail to follow that is well marked, consistent (all the breadcrumbs are from the same loaf of bread!), and easy to decipher. Good documentation always facilitates accurate project tracking, enabling you to deliver a final product on schedule and on budget.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/