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

开源日报

  • 开源日报第838期:《术语参考 whatthefuck.is》

    19 7 月, 2020
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《术语参考 whatthefuck.is》
    今日推荐英文原文:《Building an Application: Pre-Work》

    今日推荐开源项目:《术语参考 whatthefuck.is》传送门:项目链接
    推荐理由:这个项目是一个刚刚建立的前端相关术语合集,解释诸如闭包之类的常用术语。尽管现在还处在项目早期,仅有闭包这一个词汇的解释,不过在 PR 中贡献者们已经提到了相当多的常用术语,随着时间经过想必它的内容能够更为丰富。
    今日推荐英文原文:《Building an Application: Pre-Work》作者:Hannah Kofkin
    原文链接:https://medium.com/better-programming/building-an-application-pre-work-eafb660fa55e
    推荐理由:开始应用前的必要准备实现

    Building an Application: Pre-Work

    5 steps to improve organization and workflow from day one

    Building an application can be extremely complicated and time-consuming. The workflow you establish when starting your project will be the baseline for how everything to follow unfolds. If you start off disorganized and unclear, your app will suffer from it. Taking the time to develop an organized plan and set milestones from the beginning will ensure your final product can achieve its full potential.

    Let’s walk through some standard pre-work checkpoints you can use to develop a standard process for building an app. Here are the five steps to take before you jump into code mode.

    1. Outline Features

    When you have your app concept determined and are ready to start laying the groundwork, one very important first step is to decide what you actually want your app to do and how you want it to function. Writing out a list of features is a good way to compile and condense your thoughts. There are endless possibilities, so narrowing your focus from the start will eliminate wasted time down the road.

    Once you have a list of features, thinking through your MVP (or minimum viable product) is crucial. The MVP is basically the state in which your app is fully functional and able to be tested in the market for user feedback, but it leaves out some of the “stretch” features that can be added once you know your app is on track. Reaching MVP and testing in the market is useful to ensure your resources are not wasted on something that is either not necessary or is not working properly. A great tool I have used to start outlining features and deciding on MVP is Trello.

    If this step is skipped, you run the risk of trying to execute too many ideas or trying to build a feature that doesn’t relate to your user story. This is not only a waste of everyone’s time but also adds to a lack of clarity in the process and will only lead to frustration.

    Questions to ask yourself

    • What do I want my app to do?
    • What will make my app unique compared to other similar apps?
    • What is the minimum viable product I can launch with and what can be added later?

    2. Develop Domain Model

    Once the features are outlined and MVP is determined, a sensible next step is to figure out how the database will be organized. Drawing out a domain model using your features as a guide will help to visualize how the app will save and use data.

    Similarly to how an outline is created as a structure for writing an essay, it makes sense to organize your thinking, research, and structure before jumping into the code. When the time comes to build the database and the front-end interaction, the domain model will be used as your reference.

    If this step is skipped, a lot of time will go toward writing and rewriting code. All high-level details should be figured out before you write a single line of code. This organization up front allows you to focus on how to execute the ideas and build out the functionality.

    Questions to ask yourself

    • What models do I need to have in order to store correct and complete data for my features?
    • How am I going to use and access this data?
    • What are the relationships between each data table?

    3. Wireframe

    Utilizing the information outlined in Steps 1 and 2, a wireframe should be developed to lay out the user interface. Building this skeleton provides a blueprint for how each feature comes to life on the page — where it’s placed, how the data shows up to the user, and what the interaction will be. Typically, a wireframe will be built for each page view within your app. For example, Instagram has a main feed, a profile page, and a notifications page. Each of those views was carefully planned out with a focus on user interaction.

    Visualizing how your app will come to life is essential. If you build something without a plan and find it doesn’t work, you have to scrap it and start over. The blueprint phase allows you to work out any problems before they arise and figure out exactly what you want to display. Some great wireframing tools I have used are Figma, AWW App, and Axure.

    If this step is skipped, there is no reference to what you are building. If you were to design the UI as you go, a lot of energy would be spent adjusting elements on the page, using up time rebuilding code every time you find something doesn’t look right. It is also not the best practice. If you begin without a solid plan, it will show in your final product.

    Questions to ask yourself

    • Where do I want my features to show up in the app?
    • How do I want users to interact with these features?
    • What data am I accessing to display within each section of the app?

    4. Consider Edge Cases

    Before starting to build your app, it’s a good idea to think through what could possibly go wrong. A concern in programming is that a user could misuse your app or misunderstand the true intention of a feature, so it’s good to consider the outcomes and plan how to prevent your app from breaking down.

    For example, do you have a login page? On that login page, what information are you asking the user for? What validations can you add to the model to ensure the information they input is correct and complete? What is your definition of “correct and complete”?

    If this step is skipped, there is a risk that your app will be built in a way that can be easily broken. Edge cases will present themselves as you go along too, so you can’t necessarily plan for every possible problem, but anticipating what could go wrong will prepare you to figure out solutions quicker.

    Questions to ask yourself

    • How can I clearly direct users into a certain pattern through the app, keeping interactions meaningful and purposeful?
    • How could a user “break” the app? In other words, what would it mean to use the app incorrectly?
    • How can I prevent a user from breaking the app?

    5. Create Milestones

    One final step in the pre-work phase is creating a timeline. Having a detailed timeline helps to set expectations and estimate how long each feature will take to build. It’s almost impossible to know the exact timing, but working toward a goal sets an intention and helps to keep things on track.

    Another benefit of establishing a timeline is breaking a large, complicated application structure into smaller, manageable pieces. This process forces you to think about the order in which elements are built, which will make your approach more intentional when building out the functionality. For example, it makes the most sense to build out the database before building the front-end. Referring to Instagram again, having access to the user data is important before you can establish the follower interaction. If you do not build a proper database first, you will not be able to correctly build that feature.

    If this step is skipped, it can add a significant amount of stress, frustration, and time to the project. When looking at the full deliverable, it feels daunting. Breaking this down into manageable pieces not only helps maintain stress levels but allows you to compartmentalize each piece into building blocks that will integrate to form the finished product.

    Questions to ask yourself

    • How can I break down all the to-dos into small, executable pieces?
    • In what order does it make sense to build each feature? Does one feature rely on another in order to work?
    • What is my target launch date? What is realistically feasible to complete in that timeframe?

    Conclusion

    Following the five steps detailed above is critical in establishing an organized, efficient workflow before jumping into the build. Coding is tedious and complicated. Taking the time to plan ahead will save time and resources later in the process and eliminate the added stress of feeling scattered or unprepared.

    Set yourself up for success and take these necessary steps for the best possible execution of your application.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第837期:《论文社区 papers-we-love》

    18 7 月, 2020
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《论文社区 papers-we-love》
    今日推荐英文原文:《Show up for Long Enough and You Won’t Have to “Sell” Yourself》

    今日推荐开源项目:《论文社区 papers-we-love》传送门:GitHub链接
    推荐理由:Papers We Love(PWL)是一个有关计算机科学学术论文的论文库,以及围绕阅读、讨论和学习论文的社区。该项目将分散在网络上的文档集中在一起,以便使用者能够找到优质的文章。同时该社区在世界不同的城市有着分会,将不定期举办相关活动。
    今日推荐英文原文:《Show up for Long Enough and You Won’t Have to “Sell” Yourself》作者:Tim Denning
    原文链接:https://medium.com/better-marketing/show-up-for-long-enough-and-you-wont-have-to-sell-yourself-2a9bb4c01836
    推荐理由:有时推销自己或许是必要的,但也只是次要的。

    Show up for Long Enough and You Won’t Have to “Sell” Yourself

    It’s hard work being forced to pitch yourself every day — especially when you don’t have to

    We’re all salespeople whether we admit it or not. You’re selling yourself, an idea, a business, an opportunity, or a person on a daily basis.

    I stopped selling myself as a writer about two years ago, accidentally. It was only recently that I figured out why, and it will help you when thinking about your own life.

    There Are Two Ways to Sell Yourself:

    1. Jam your brand and business card down people’s throats.
    2. Sit back and let people come to you.
    It’s hard work to try and convince people about what you have to offer and your value. Imagine living life as if it were a 365-day job interview. That’s how a lot of people live and it’s exhausting to have to tirelessly sell yourself.

    Time in the Game

    The subtle difference in my life has been time in the game — specifically, time spent on social media and writing blog posts.

    I have been doing it for so long now that I’ve almost completely given up the notion of selling who I am and what I do — a Google Search does that for me.

    People respect how much time and effort you’ve put into something. It shows that you’re serious and can be counted on. So spending several years following one path can lead to enormous results.

    You don’t have to pitch yourself so much when you’ve been doing your thing for a long time. People come to you because they’ve seen your work.

    Become Known for One Skill

    We’ve all seen a LinkedIn profile that says Entrepreneur, Speaker, Award-Winning Founder, Blockchain Enthusiast, Love Of Dogs, Part-time Astronaut. It’s all too much. What do they do? Who knows. Perhaps dabble in a lot and achieve not much.

    I saw a LinkedIn profile today with a killer headline from a guy named Saurabh Srivastava.

    It read: “I write.”

    Simple. Beautiful. Elegant. Subtle. But bold at the same time. It takes a lot of guts to be that specific and focused.

    If people don’t know you for one skill, then they become confused, and that’s when you have to sell yourself over and over.

    People know one thing about me: I write.

    How could you take what you do and make it less confusing? There must be one skill or one passion you want people to associate with your name.

    Confusion leads to the need to “sell.”

    Clarity and focus lead to a self-fulfilling prophecy where you sell yourself without opening your mouth.

    Add a Heart of Gold

    Heart sells you.

    Acting with heart is so rare and that’s why it sells you and what you do so well. You don’t have to be Mother Teresa either.

    Display raw emotion, show people you care, see yourself as part of something bigger, spread love not hate, and help people for no good reason at all.

    Final Thought

    Every day you’re selling. And selling can be easy.

    Ditch the personal branding gurus, social media seminars full of selfishness, marketing guides for $99 a month, and people teaching a form of hypnosis that’s supposed to make someone buy what you do.

    If you show up for long enough with an aim to be helpful and put your ego to one side, you’ll sell yourself better than any marketer ever could.

    Time in the game beats time spent trying to convince people of your value.

    Your process and the length of time you spend doing it sells you. When you do that you might just accidentally see a powerful shift from selfish to selfless.


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

    17 7 月, 2020
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《tsunami-security-scanner》
    今日推荐英文原文:《Mozilla launches VPN service to help protect your privacy》

    今日推荐开源项目:《tsunami-security-scanner》传送门:项目链接
    推荐理由: Tsunami是具有可扩展插件系统的通用网络安全扫描程序,可用于检测高严重性漏洞。Tsunami需要依赖其插件系统来提供基本的扫描功能。所有公开可用的Tsunami插件都托管在单独的google / tsunami-security-scanner-plugins仓库中。
    今日推荐英文原文:《Mozilla launches VPN service to help protect your privacy》作者:Steven Musil
    原文链接:https://www.cnet.com/news/mozilla-launches-vpn-service-to-help-protect-your-privacy/
    推荐理由:Mozilla公司在周三宣布它的vpn服务已经支持windows,对安卓设备的支持将也会在本周完成.这项举措可以给Mozilla公司一点财务自由.

    Mozilla launches VPN service to help protect your privacy

    Mozilla announced Wednesday that its virtual private network service is now available on Windows, with support for Android devices scheduled to arrive later this week. The release could give Mozilla, the maker of the Firefox web browser, a little financial independence.

    The $4.99 monthly service will be available initially in the US, Canada, the UK, Singapore, Malaysia and New Zealand.

    VPNs act as an encrypted tunnel for transferring data on the internet, helping to protect sensitive information in transit. Originally developed as a tool of the business world, VPNs are used by a quarter of internet users for hiding online activity, bypassing internet censorship in countries without a free internet and avoiding geography-based restrictions on streaming services. VPNs also can obscure internet addresses, making it harder for advertisers, publishers and data brokers to track you online.

    Mozilla, which has been beta testing the service for nearly a year, says the VPN service promises a faster browsing experience because of its leaner structure. The Mozilla VPN is based on WireGuard protocol’s 4,000 lines of code, less than a third of the average VPN service provider.

    While the move is part of Mozilla’s recent privacy push, it could also offer the company some financial wiggle room. Mozilla makes money through search ad deals, notably with Google, in which it’s paid for sending Firefox users’ search queries to Google. Google shows ads next to the search results and browser makers including Mozilla often get a cut of the proceeds.

    Building a VPN for people willing to pay for increased privacy would give Mozilla another way to bring in money. Mozilla previously tested offering a VPN service for $10 a month.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第835期:《404-PageNotFound》

    16 7 月, 2020
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《404-PageNotFound》
    今日推荐英文原文:《On Sustainable Software Development》

    今日推荐开源项目:《404-PageNotFound》传送门:项目链接
    推荐理由:404 错误应该算是每个网站都不可避免的了,而如何设计自家网站的 404 页面也算得上是门学问。这个项目收集了各个网站上的 404 页面,便于以这些页面为原材料寻找灵感,看到设计的好的还可以顺手点个赞。

    今日推荐英文原文:《On Sustainable Software Development》作者:Dan Goslen
    原文链接:https://medium.com/dev-genius/on-sustainable-software-development-69acd0749559
    推荐理由:一直通过超负荷来完成任务不能算是健康的开发过程

    On Sustainable Software Development

    “Hero” programming only lasts so long.

    It’s 9:45 pm on New Year’s Eve. I was supposed to be downtown a few hours ago with a group of friends to and stay up to be part of the Raliegh NYE celebration (which, btw, features an acorn drop).

    Instead, I was on my computer. Hunched over, manually verifying the last of our billing statements were ready to go out. The past day had been an exhausted one. Every process had gone wrong, no one was around due to the holiday, but we had to get statements out.

    We thankfully did, and everything was fine.

    Except it wasn’t fine.

    It wasn’t fine that I was still in the office.

    It wasn’t fine that I had broken promises to my friends because of work.

    It wasn’t fine that we were keeping this system afloat by sheer willpower.

    Software Development Shouldn’t Be Heroics

    How many of you have worked on a team that always had to be putting in “heroic work” or were always “stepping up to the plate” in 11th-hour situations? Were it was normal for team members to work late, over the weekend, or skip lunch — or all three.

    These teams usually get praised if they hit the deadline, and their achievement is hailed as “grit” or “great work.” If they miss the deadline, though — they are scolded for not making the deadline and wind up working just as long to get in done when they can.

    While these situations are nearly inevitable — every team will hit some form of crunch time that requires some extra work — it should be the norm. And it shouldn’t be seen as heroic work.

    When teams are constantly in this state of frantic overwork, something is just plain wrong. They aren’t building the right software. They aren’t investing in the right places. They aren’t having the correct retrospectives with themselves or with product owners. Something needs to change.

    Development Should be Sustainable

    One of the core principles behind the Agile Manifesto is
    Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    Its often an overlooked one too. Why?

    I believe it’s because teams that embrace all the other principles — continuous delivery, short iterations, prioritizing developer efficiency, etc. — leads naturally to a sustainable pace. It also means that if a development team is doing those things well, there can be useful estimates from the team about when they can complete work. This makes product owners happy as their job of predicting features to users, and setting direction for the product is now more straightforward.

    I also think there is a slight tendency for developers to want to be perpetually busy. There is a false sense of meaning that comes from always being busy, isn’t there? Our whole society says that if we are busy or hustling or continually working that we are doing something meaningful.

    I’m not condemning hard work at all! I am simply saying there are more meaningful things than working long hours to fix a bug on New Year’s Eve.

    How to Get There

    How does one take a team that regularly feels up against the wall or behind and create a sustainable cadence?

    I’ll be blunt: it won’t be simple or easy. Chances are you will find that there is pushback from not only the product owners or managers but even pushback from the team. Teams who have lived in this “hero” world might start to think they won’t get noticed or that they won’t be needed. Change is hard.

    In my experience, getting onto a path towards sustainable pace requires a few things:
    1. Admit the team is overworked. This is harder than you might think. Some developers don’t want people they work long hours because they are afraid it means they will look inadequate (i.e., “You had to work the weekend to finish that simple task?”). The team and managers need to agree.
    2. Start holding a retrospective. It doesn’t need to be an hour-long, and it doesn’t need to be every two weeks. Heck, you don’t even need a big meeting to start. Create a shared document and pass it around, asking team members to add things they would think the team should keep doing, stop doing, and start doing. After a day or two, share the feedback during your typical standup or set up a 15-minute summary.
    3. Identify from your retrospectives one thing — yes, one thing — to try. It could be starting something, stopping something, investing in a system, etc. Just pick something you think will help your team.
    4. Keep doing that over and over!
    It sounds too simple, right? The truth is that this process is simple. It’s a framework for the team to own something they think will make them better. Given that chance, most engineers will go to things that will improve their codebase and their lives overall.

    It’s just also hard to follow. It takes real work and a commitment to change for a retrospective process to make an impact. Everyone needs to commit to the process, and everyone needs to be honest about their opinion.

    Before wrapping up, consider your team’s “one thing” for a retrospective to define what constitutes an emergency and what does not. Define if there are cases in which someone needs to work late or over the weekend to complete or when it can wait till the next workday. This definition is important because it will help your team get out of the feeling of perpetually being against the wall.

    Development shouldn’t be a constant state of exhaustion and hero programming. We need to work together as teams to create sustainable workflows that allow our teams to build software effectively for the long-haul. I hope this guide helps you and your team!

    Happy coding!
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
←上一页
1 … 49 50 51 52 53 … 262
下一页→

Proudly powered by WordPress