Friday Links 304

  • Orleans 2.0 | Microsoft Orleans Documentation
  • sdras/project-explorer:  CLI tool to create an annotated tree visualization of any project
  • lesnitsky/git-tutor: +md= Awesome tutorials from your git log
  • Video Indexer – General availability and beyond | Blog | Microsoft Azure
  • Creating blocks · elaval/Firstmakers-Blockly Wiki
  • Productive Rage – I didn’t understand why people struggled with (.NET’s) async
  • Creating PDF files in ASP.NET Core | Software Engineering
  • Chirp | Send data with sound
  • Fody/ConfigureAwait: A Fody Addin
  • HTTP-REPL Tool to test WEB API in ASP.NET Core 2.2
  • Enzyme: digesting even faster | Szymon Kulec `Scooletz`
  • The Microsoft Infer.NET machine learning framework goes open source – Microsoft Research
  • Rent-scraping: How I saved money using R – Embracing the Random
  • Muze Examples
  • APK Expansion Files  |  Android Developers

    • OpenSource library- conclusion

    Part 1

    Implement Open-source library guidance

    Part 2

    OpenSource library – Cross-platform targeting

    Part 3

    OpenSource library-Dependencies

    Part 4

    OpenSource library- Source Link

    Part 5

    OpenSource library-versioning

    Part 6

    OpenSource library- Breaking changes

    Part 7

    OpenSource library- conclusion

    Following the guidance from https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/ it is somehow simple. Most of the rules are already implemented, other are easy to implement into a DevOps Continous Integration workflow( such as Azure DevOps) and others are hardly one half a hour.

    It will be nice if we have a badge for this – I will consider making this some day ….

    Friday Links 303

  • Build your first Angular app | Scrimba.com
  • The Economist’s Big Mac Index is calculated with R (Revolutions)
  • TheEconomist/big-mac-data: Data and methodology for the Big Mac index
  • Introducing SimpleSamSettings – CodeProject
  • The Twelve-Factor App
  • 12 Factor CLI Apps – Jeff Dickey – Medium
  • User Timing API – Web APIs | MDN
  • Extract Tables from PDFs – CodeProject
  • SQL Tutorial with Exercises – SQL Server | Ram Kedem
  • SQL Exercises, Practice, Solution – w3resource
  • SELECT basics – SQLZOO
  • Caching Arguments  |  Blockly  |  Google Developers
  • victorqribeiro/imgToAscii: A JavaScript implementation of a image to Ascii code
  • LinkGenerator in ASP.NET Core 2.2 – Shawn Wildermuth
  • Guidance for library authors | .NET Blog

    • OpenSource library- Breaking changes

    Part 1

    Implement Open-source library guidance

    Part 2

    OpenSource library – Cross-platform targeting

    Part 3

    OpenSource library-Dependencies

    Part 4

    OpenSource library- Source Link

    Part 5

    OpenSource library-versioning

    Part 6

    OpenSource library- Breaking changes

    Part 7

    OpenSource library- conclusion

    Following guidance from https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/breaking-changes

    Nr

    Recomandation

    AOP Roslyn

    1

    DO think about how your library will be used. What effect will breaking changes have on applications and libraries that use it?

    2

    DO minimize breaking changes when developing a low-level .NET library.

    3

    CONSIDER publishing a major rewrite of a library as a new NuGet package.

    4

    CONSIDER leaving new features off by default, if they affect existing users, and let developers opt in to the feature with a setting.

    5

    DO NOT change an assembly name.

    6

    DO NOT add, remove, or change the strong naming key.

    7

    CONSIDER using abstract base classes instead of interfaces.

    8

    CONSIDER placing the ObsoleteAttribute on types and members that you intend to remove. The attribute should have instructions for updating code to no longer use the obsolete API.

    9

    CONSIDER keeping types and methods with the ObsoleteAttribute indefinitely in low and middle-level libraries.

    Unfortunately, AOP Roslyn is not in the stage of breaking changes. But I have had another library, Exporter, and I have had made  3:  CONSIDER publishing a major rewrite of a library as a new NuGet package

    Friday Links 302

  • Year 1 as an endjin software engineering apprentice | endjin blog
  • 10 Points to Secure Your ASP.NET Core MVC Applications – CodeProject
  • Tour Through the OWASP Top 10 Critical Web Application Security Risks
  • ASP.NET Core 2.2 Parameter Transformers for clean URL generation and slugs in Razor Pages or MVC – Scott Hanselman
  • Development With A Dot – Performance in .NET – Part 2
  • rjperes/Interpose.Core
  • Web API Error Handling: How To Make Debugging Easier
  • https://dms.licdn.com/playback/C5605AQExygyk35c3uw/7adf45d14f7a4e9f8fc1c60dcfe1099a/feedshare-mp4_3300-captions-thumbnails/1507940147251-drlcss?e=1541260800&v=beta&t=8muVWqSFZ_cN-AxA6tRZTL845YldP1kYYCcF_U55yrg
  • Ten Agile Axioms That Make Managers Anxious
  • Fed up with cloud giants ripping off its database, MongoDB forks new ‘open-source license’ • The Register
  • DIB_DETECTING_AGILE_BS_2018.10.05.PDF
  • 99 Collaboration Apps You Should Know in 2019
  • Eliminate an entire category of bugs with a few simple tools
  • Passing an ILogger to Polly Policies – Steve Gordon
  • How to write a killer Software Engineering résumé – freeCodeCamp.org

  • [ADCES] Post Event AzureDevOps

    I have had a presentation at ADCES ( https://www.meetup.com/Bucharest-A-D-C-E-S-Meetup/events/257585167/ ). It was about AzureDevOps, Angular and .NET Core – real world scenario to create a build from GitHub application . The Example will be Stankins pipeline , https://github.com/ignatandrei/stankins/blob/master/azure-pipelines.ymlYou can find the presentation at https://github.com/ignatandrei/Presentations/tree/master/2018/shorts/AzureDevOps 

    See you next time!

    OpenSource library-versioning

    Part 1

    Implement Open-source library guidance

    Part 2

    OpenSource library – Cross-platform targeting

    Part 3

    OpenSource library-Dependencies

    Part 4

    OpenSource library- Source Link

    Part 5

    OpenSource library-versioning

    Part 6

    OpenSource library- Breaking changes

    Part 7

    OpenSource library- conclusion

    Following recommendations from https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/versioning

    Nr

    Recomandation

    AOP Roslyn

    1

    CONSIDER using SemVer 2.0.0 to version your NuGet package.

    		 NO

    2

    DO use the NuGet package version in public documentation as it’s the version number that users will commonly see.

    		 Yes

    3

    DO include a pre-release suffix when releasing a non-stable package.

    		 No

    4

    CONSIDER only including a major version in the AssemblyVersion

    		 Yes

    5

    CONSIDER keeping the major version number of the AssemblyVersion and the NuGet package version in sync.

    		 Yes

    6

    DO NOT have a fixed AssemblyVersion

    		 Yes

    7

    CONSIDER including a continuous integration build number as the AssemblyFileVersion revision

    		 Not needed

    8

    AVOID setting the assembly informational version yourself.

    		 Yes

    For 1: I do not like SemVer. It is putting some pressure on the developer of the OpenSource. So I decide to follow Calendar versioning https://calver.org/ 

    For 2: Yes, it is normal.

    For 3: No, I do not like pore-release.

    For 4: Yes – the year is major

    For 5: Yes, done by CI process

    For 6: Yes, done by CI in Calendar Versioning

    For 7: NO. And , because of Calendar versioning, it is already done, if I do not publish 2 versions in the same day

    For 8: Do nothing – and it is done.

    Friday Links 301

  • EntityFrameworkCore Logging in ASP.NET Core – Shawn Wildermuth
  • Locating special folders in cross-platform .NET applications – RHD Blog
  • My Biggest Regret in the knitr Package – UTF-8, and UTF-8 only, or we cannot be friends – Yihui Xie |
  • How Developers Stop Learning: Rise of the Expert Beginner – DaedTech
  • Development With A Dot – .NET Core Service Provider Gotchas and Less-Known Features
  • netgusto/nodebook: Nodebook – Multi-Lang Web REPL + CLI Code runner
  • Advanced R
  • CDL-AD(2018)021
  • Open-source library guidance | Microsoft Docs
  • Automated Testing on Devices – Netflix TechBlog – Medium
  • Digital Transformation cartoon | Marketoonist | Tom Fishburne
  • Marketing Automation cartoon | Marketoonist | Tom Fishburne
  • Drawing beautiful maps programmatically with R, sf and ggplot2 — Part 1: Basics
  • The NFL, NBA, & MLB’s Center of Gravity · Chad Bixby
  • Getting to Know Basel’s Districts

    • OpenSource library- publishing

    Following the rules at https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/publish-nuget-package

    Nr

    Recomandation

    AOP Roslyn

    1

    DO publish stable packages and pre-release packages you want community feedback on to NuGet.org.

    		 Done

    2

    CONSIDER publishing pre-release packages to a MyGet feed from a continuous integration build.

    		 No

    3

    CONSIDER testing packages in your development environment using a local feed or MyGet. Check the package works then publish it to NuGet.org.

    		 Yes

    4

    DO use a Microsoft account to sign in to NuGet.

    		 Yes

    5

    DO enable two-factor authentication for accessing NuGet.

    		 Yes

    6

    DO enable email notification when a package is published.

    		 Yes

    For 1: Done already. However, I do not like pre-release packages

    For 2: Too much hassle for a single developer. Using instead NuGet

    For 3: Yes , I have already a build.bat to do this

    For 4: Yes.(NuGet allows only that now)

    For 5 : Yes

    For 6: Yes.

    Friday Links 300

  • Dimensionality Reduction Methods Using FIFA 18 Player Data · David Schoch
  • CaptionBot – For pictures worth the thousand words
  • 20 Creative Ways to Use Trello and Organize Everything
  • ardalis/CleanArchitecture: A starting point for Clean Architecture with .NET
  • Cross-platform Time Zones with .NET Core | .NET Blog
  • dazinator/Dazinator.AspNet.Extensions.FileProviders
  • File Providers in ASP.NET Core | Microsoft Docs
  • System-IO-Abstractions/System.IO.Abstractions: Just like System.Web.Abstractions, but for System.IO. Yay for testable IO access!
  • Code Coverage is Finally Easy in .NET Core – CodeProject
  • ASP.NET Core 2.2 Health Checks Explained | elmah.io
  • Development With A Dot – .NET Core Service Provider Gotchas and Less-Known Features
  • Testing SignalR Hubs in ASP.NET Core 2.1 – CodeProject
  • Export to Excel using NPOI – C# and WEB API – CodeProject
  • Observability as code, secrets as a service, and chaos katas: ThoughtWorks outlines key engineering techniques to trial and assess | Packt Hub
  • Monitoring and Observability — What’s the Difference and Why Does It Matter? – The New Stack

    • Andrei Ignat weekly software news(mostly .NET)

    * indicates required

    Please select all the ways you would like to hear from me:

    You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please visit our website.

    We use Mailchimp as our marketing platform. By clicking below to subscribe, you acknowledge that your information will be transferred to Mailchimp for processing. Learn more about Mailchimp's privacy practices here.