I recently started a new project on GitHub: a library and a set of Windows, command line and web application to easily generate pass-phrases using Italian language dictionary.
I created the project in Visual Studio Community 2015 and created the online repository with the integrated extension: everything seemed normal except for one small detail.
The language details is the colored bar with details about the programming language used in the project: it was all wrong!
It showed programming languages I did not even know they existed, let alone used!
As GitHub uses an automatic system to determine the language used in a project, I started to think what could have fooled it into thinking my project was created with such exotic languages.
The easier answer to this question was the data contained into the italian dictionaries: a long list of common and uncommon italian words needed to generate random pass-phrases.
There is a simple method to override the automatic selection by let GitHub know what files needs to be ignored because imported from other libraries or because they are part of the Linguist documentation files.
So I edited the .gitattrtibutes file by adding:
$ cat .gitattributes
So instructing GitHub to identify all the files in the subfolder PassaFraseCore/Dizionario as Linguist
And the result was much better!
For the most part of the websites I am owner of, I normally use Visual Studio to code and test locally, then I publish them to the FTP folder provided from my hosting company.
When I first set that publish up I was asked for the obvious few information needed to complete the process: the FTP address, username and password for login and the publish folder (as it is normal fro the hosting company to use shared resources for low-cost hoisting, they normally use a common FTP with the customers isolated through the use of folders normally named after the domain name).
After starting the publish procedure, I was reminded by Visual Studio that my credentials were transmitted insecurely over the net in plain text.
Of course this rang a warning bell in my head, so I cancel the procedure and thought for a while.
I realized during the setup process I was not asked what authentication method I wanted to use: I normally use FTP Secure protocol when available and, if not available, I think twice about commit myself to a company who is not offering it.
I doubled checked the Visual Studio configuration and I was more than surprised not finding any options for this; a search on Google also proved to be inconclusive.
Then I tried the simplest solution of all that, not surprisingly, worked properly: simply add the ftps: scheme name at the beginning of the address to let Visual Studio to automatically switch to secure connection.
So, to make the long story short, simply replace the connection string that will look like
and Visual Studio will automatically use TLS encryption to connect.
At the first publish attempt, the digital certificate is shown so you can validate the authenticity of the site and you have the option to remember that certificate as valid for that moment on.
At the end of the day I was a little surprised this option was not clearly shown in Visual Studio as it could fool a programmer not familiar enough with security or simply too distracted to notice the lack of it with the standard settings.
Since a few days, my Visual Studio 2013 is behaving strangely: a few apparently random error here and there, but nothing really serious and not solvable by the usual save-the-day restart.
Of course I promised myself to eventually have a closer look at the issue and I was force to do so this morning when VS stopped to work properly.
I first noticed the left margin where line numbers and “+” sign for the code collapsing was missing, a strange error was shown at startup and finally, worse of all, the Reference Manager refused to work properly crashing the entire Environment trying to load the lists.
After a brief internet search i found a useful post on the usual StackOverflow with a link to this MSDN documentation.
It seemed a good idea to have a look at my temp folder located – for Windows NT-like operating systems – at
in fact I found a huge number of TMP files together with thousands of other files and hundred of folders
The need for a temporary storage is evident to any programmer and to any serious computer worker, but it appears the vast majority of applications treat this place as unlimited space with no rules and with the assumption someone else is going to periodically clear it.
I started by deleting files with command line in order to speed up the process, then I tried to clean up folders. Some of them were in use and so not removeable. So I had a look at the locking process using the excellent tool LockHunter: this way I had the chance to learn a little bit more about the misbehaving applications and to release temporary files by cycling close and open the interested application.
Lessons for today: for the developers, follow your parents’ advice to clean up your own mess, now including your own application’s mess!
When your application creates temporary files, try to clean them up, inform the user and document what the application is doing.
For the (power) users, the suggestion is to keep a closer look to this folder and clean it when the number of folders and file clearly became unreasonable.
There are plenty of programming languages out there and they all allow endless possibility in how to write a piece of code.
Very often things can be done in two ways: the blunt way and the elegant way.
Consider for instance this piece of code:
For Each SingleFeed As XElement In XMLDoc.Descendants(XName.Get(CurrentFeed.RootElement))
Dim SyndFeed As SyndicationFeed = SyndicationFeed.Load(System.Xml.XmlReader.Create(SingleFeed.Descendants(XName.Get("feed")).Value.ToString))
Dim TempItems As New List(Of SyndicationItem)
If SyndFeed.Items.Count >= CurrentFeed.TotalElements Then
It has to do with the creation of an object to store items from an ATOM feed.
The important point I want to show is the one about the If … else … End If cycle. What you are looking here is the first implementation of the code: it’s the easy way and, as i discovered later, the longest and stupidest way to write it.
Yes, it was stupid: the compact, most logical and briefly the elegant way to wrote it turned out to be:
TempItems.AddRange(SyndFeed.Items.ToList.GetRange(0, Math.Min(CurrentFeed.TotalElements, SyndFeed.Items.Count)))
Probably any coding language nowadays includes some kind of Minimum function to return the smallest of two numbers.
Very often is just a matters of knowing what you are doing.
Earlier today I was creating a new class file for a project of mine in Visual Studio.
Then I went on using the class defined in that file in a web form, but, to my surprise, the class was inaccessible.
I double checked the access level of the class, but it appears that wasn’t the issue, so I started googling for this problem, but I ended up looking at situation different from mine and not really useful.
After a few minutes of scratching my head on this unusual problem, I finally had a look at a pane I rarely look at:
In the Properties pane, the Build Action was set to Content instead of Compile: this is the ways of telling the IDE to include this file in the project as a static resource. So, in this case, the class file was included as a simple plain text file with no action performed on it: no compilation mean of course no usable class, so that was the reason for the seemingly inexplicable behavior.
To have a deeper look into this topic, I strongly advise to read this interesting post on StackOverflow.