Friday links 229

  1. 10 Free Add-ins For Microsoft Office that Improve Productivity
  2. blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html
  3. venturebeat.com/2016/03/20/why-indoor-location-tech-is-facing-an-uphill-battle/
  4. The Joel Test: 12 Steps to Better Code – Joel on Software
  5. https://segment.com/blog/the-deep-roots-of-js-fatigue/
  6. sethgodin.typepad.com/seths_blog/2016/03/what-are-you-competing-on.html
  7.  mperdeck/LINQtoCSV: Popular, easy to use library to read and write CSV files.
  8. DefinitelyTyped/jsnlog.d.ts at master · DefinitelyTyped/DefinitelyTyped
  9. Event processing at all scales with Reactive Extensions | Techdays 2014 the Netherlands | Channel 9
  10. Consider app.config remapping of assembly warning after upgrade with Nuget | The ASP.NET Forums
  11.  Legacy Code for Developers: Managing your Manager – NDepend
  12.  Docker Toolbox | Docker
  13. Build Lambda Expressions Dynamically – CodeProject
  14. Build Where Clause Dynamically in Linq – CodeProject
  15. Spying on Razor View Compilation
  16. Sinon Tutorial: JavaScript Testing with Mocks, Spies & Stubs
  17.  ClipX
  18. Immutability is not enough
  19. Microsoft/BotBuilder: The Microsoft Bot Builder SDK is one of three main components of the Microsoft Bot Framework. The Microsoft Bot Framework provides just what you need to build and connect intelligent bots that interact naturally wherever your users a
  20. Bot Framework Emulator
  21. Bot Framework 
  22.   evanw/thinscript: A low-level programming language inspired by TypeScript
  23. toddmotto/public-apis: A collective list of public JSON APIs for use in web development.
  24. Testing with mocha and jsdom ∙ Babel Starter Kit
  25. https://www.kriasoft.com/babel-starter-kit/recipes/testing-with-mocha-and-jsdom

Developing an outlook helper–part 2 from 5–VBA

Series

 

Developing Outlook helper – introduction

Developing Outlook helper-VBA macro

Developing Outlook helper-C#

Developing Outlook helper – javascript for Office 365

Developing Outlook helper – conclusions

Develop like it was ‘9x:

In the early days to develop an outlook addon it was simple : Press ALT+F11 and wrote the VBA. ( in our days , you go to the outlook settings and enable macros)

The code will be something like this:

Public Sub IsUserInEmail()
    Dim current
    Set current = Application.ActiveInspector.CurrentItem
    
    If Not TypeOf current Is MailItem Then Exit Sub
    Dim m As MailItem
    Set m = current
    
    Dim name As String
    name = InputBox("Please give me the user name", "Find User")
    If (Len(name) = 0) Then Exit Sub
    
    
    If (InStr(1, m.To, name, vbTextCompare) > 0) Then
        MsgBox "The name " & name & " has received the email"
        Exit Sub
    End If
    If (InStr(1, m.Sender.name, name, vbTextCompare) > 0) Then
        MsgBox "The name " & name & " has received the email"
        Exit Sub
    End If
    Dim rec As Recipient
    For Each rec In m.Recipients
        If (InStr(1, rec.name, name, vbTextCompare) > 0) Then
            MsgBox "The name " & name & " has received the email"
            Exit Sub
        End If
    Next rec
    MsgBox "The name " & name & " has NOT received the email"
    
End Sub

Test like it was ‘9x:

If you want to test, open the email ( double click the email) . Then run with F5 and debug.

Deploy like it was ‘9x:

Send to the user the VBA script and tell him step by step how to copy / paste

Developing an outlook helper–part 1 from 5

Series

 

Developing Outlook helper – introduction

Developing Outlook helper-VBA macro

Developing Outlook helper-C#

Developing Outlook helper – javscript for Office 365

Developing Outlook helper – conclusions

I want to show how much the software have changed from the early days to now.

For this , I will show it was / is to develop / test / deploy a sample outlook macro/application that allows the user to find if a name is between the email addresses from an email ( in a international company this is rather a difficult task).

The part 2 will be implementation as  an Outlook VBA Macro

The part 3 will be a VS addon application

The part 4 will be a modern Javascript Office 365 application

In the part 5 I will put the conclusions – but I think that you have an idea about what I am talking.

ImageTagHelper in .NET Core–add data URI scheme

The ImageTagHelper in ASP.NET Core MVC (https://github.com/aspnet/Mvc) is lacking one attribute that I find somehow useful: a data uri to embed the image as base64 (https://en.wikipedia.org/wiki/Data_URI_scheme )

I was curious about how fast it will be to make such a modification on my PC.

So the process was:

  1. Downloading branch rel/1.1.1 from https://github.com/aspnet/Mvc as a zip file
  2. Unlock the file, unpack, run  MVC.sln with VS2015
  3. Compile the entire project.
  4. See tests  ( also run dotnet test in the Mvc-rel-1.1.1\test\Microsoft.AspNetCore.Mvc.TagHelpers.Test to figure what was missing)
  5. Started modifying the file ImageTagHelper( adding
     public bool RenderBase64 
    

    and creating FileBase64ContentProvider.cs with the (approximately) same content as FileVersionProvider

  6. Adding tests to  mvc-rel-1.1.1\test\microsoft.aspnetcore.mvc.taghelpers.test\imagetaghelpertest.cs  ( also modifying mocker –
    for my purposes, to read the file, I need file length

                mockFile
                    .Setup(m => m.CreateReadStream())                
                    .Returns(() => new MemoryStream(Encoding.UTF8.GetBytes("Hello World!")));
    mockFile.SetupGet(f => f.Length).Returns(12);
                
    
  7. Modifying HtmlTargetElement attribute from ImageTagHelper
  8. Adding “Microsoft.AspNetCore.StaticFiles”: “1.1.0”, and app.UseStaticFiles();  to HtmlGenerationWebSite and going to http://localhost:5551/HtmlGeneration_Home/image

And that was all. Now I will see how to fork and submit changes 😉

Later Edit: Submit a bug, fork, pull request. Approved.
https://github.com/aspnet/Mvc/issues/5694

7 rules of logging ( and 7 notes)

Those are my 7 rules for logging (you can read also the side note for every rule)

So here they are:

  1. Logging is good for developers, not for the user .
  2. You should not re-invent logging framework – just use one that exists in your programming language.
  3. The logging should not affect the usual behavior of the program.
  4. You should log everywhere there is a layer made by you (including GUI).
  5. If the software returns/throws a generic code for error,then he should log the concrete details of what happened and the time * although this should be automatically done by the logging framework).
  6. The logging should be easy to configure ( where to log, what to log ).
  7. The format in which are you logging should be easy to understand by an automatic text parser

Note 1: Corollary : Every software needs logging and this should be performed as good as possible , with all specific details to understand the problem.

Note 2 : Choose one that works well in multi-threaded application, has multiple outputs ( database, log file, console , others) and provides various levels of logging( at least debug, info , error). For   .NET : log4net, nlog .  Do re-invent the wheel – if you believe that you can make something better .

Note 3 :  For example logging a function that modifies some parameters or logging variable.ToString() and this throws the infamous “null reference”

Note 4 : See http://liddellj.com/2014/09/09/log-all-the-things 

Note 5 : For example, if you throw a generic exception “ Something bad happened “ in order to not bother the user with mundane details, you should log the primary error and the reason that you throw the generic exception

Note 6:  This means it is easy for DevOps to configure the software to not log into production the debug levels .

Note 7: See http://dev.splunk.com/view/logging-best-practices/SP-CAAADP6