Here is the list of top 10 excuses you are likely to hear if you work with a programmer!
10. “I haven’t touched that module in weeks!”
9. “It must be a hardware problem.”
8. “Somebody must have changed my code.”
7. “Did you check for a virus on your system?”
6. “You must have the wrong version.”
5. “That’s weird…”
4. “There must be something wrong with your data”
3. “It has never done that before.”
2. “It worked yesterday.”
… and, by far the best one:
1. “It works on my machine”
Software development is not a Jenga game.
Single Responsibility Principle
Just because you can, doesn’t mean you should.
Open Closed Principle
Open chest surgery is not needed when putting on a coat.
Liskov Substitution Principle
If it looks like a duck, quacks like a duck, but needs batteries – you probably have the wrong abstraction
Interface Segregation Principle
You want me to plug this in, where?
Dependency Inversion Principle
Would you solder a lamp directly to the electrical wiring in a wall?
If you are working with Microsoft Cloud, you must have had the need to move a few files (in bulk) from a folder onto the Azure Storage System.
To get started, you will need to have a Microsoft Azure Account, create a storage account, get the connection string for it.
If you are unsure about how to proceed, check out this great introductory article: How to use Blob Storage from .NET
This is a demo connection string that you will need to add to your web.config file:
<add key="StorageConnectionString" value="DefaultEndpointsProtocol=https;AccountName=srmd1983;AccountKey=JyUOu3/iv+0UMjzI/PtoHd2JKhKx4SOSSxJcsvVp95isAZH6hKpPs/AQDOPxgVXjTNGWCYCSssgiwVVun0rlWXFgJ6A==" />
In your code, import the needed Microsoft.WindowsAzure.Storage namespace. To add this DLL, install the Azure SDK package for your version of Visual Studio and add the DLL into references.
Then you will need to create a method that will do all the dirty work. The files will be uploaded in a subdirectory for each folder (in this case, the subdirectory is generated by the ClientID value).
1: Imports Microsoft.WindowsAzure.Storage
2: Imports Microsoft.WindowsAzure.Storage.Auth
3: Imports Microsoft.WindowsAzure.Storage.Blob
4: Imports System.IO
5: Public Class Azure
6: Shared Function UploadAllFilesToBlob(ClientID As String) As String
7: Dim err As String = ""
9: Dim storageAccount As CloudStorageAccount = CloudStorageAccount.Parse( _
11: Dim blobClient As CloudBlobClient = storageAccount.CreateCloudBlobClient()
12: ' // Retrieve a reference to a container.
13: Dim container As CloudBlobContainer = blobClient.GetContainerReference("uploads")
14: '// Create the container if it doesn't already exist.
16: Dim dir As CloudBlobDirectory
17: dir = container.GetDirectoryReference(ClientID)
18: '// Create or overwrite the "myblob" blob with contents from a local file.
19: Dim path As String = System.Configuration.ConfigurationManager.AppSettings("SavePath")
20: Dim di As New DirectoryInfo(path)
21: For Each fi As FileInfo In di.GetFiles()
22: Dim fileStream = System.IO.File.OpenRead(fi.FullName)
23: ' // Retrieve reference to a blob named the same as the uploaded file. If the file exists, it will be overwritten.
24: Dim blockBlob As CloudBlockBlob = dir.GetBlockBlobReference(fi.Name)
25: '//create or replace
26: fileStream.Position = 0
31: Catch ex As Exception
32: err = "Error: " + ex.Message + "<br />" + ex.StackTrace
33: End Try
34: Return err
35: End Function
By definition, every TCP/IP application is a client/server application. In this scenario the client makes requests of a server. That request flows down the TCP/IP protocol stack, across the network, and up the stack on the destination host. Whether the server exists on the same host, another host of the same LAN, or on a host located on another network, the information always flows through the protocol stack.
From the information presented to this point, the client/server model has some general characteristics:
By specifying only the interface between the Application layer and the Transport layer, the TCP/IP Application layer permits various Application layer models. This open-ended approach to the Application layer makes it difficult to draw a single model that illustrates all TCP/IP applications. On one end of the scale, applications run as shell-level commands; on the other, applications run in various window environments. For example, the traditional telnet is run from the shell. Yet, some implementations of the telnet client take advantage of windows technology. To make life more complicated, telnet implementations are also available for the distributed computing environment (DCE). C++ client/server applications use the Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA) model. Consequently, trying to define a universal Application layer model is an exercise in futility.
However, even with all the variations, the Web browser continues to grow as a popular Windows environment for the implementation of the client side of the equation.
Not too long ago, programmers developed applications; now they develop applications, plug-ins, and applets. Although a program is a program, the name attached to it tells us something about the nature of the program. Alas, there are more gray zones than black and white ones. In spite of this overlap, some well-defined characteristics separate applications, plug-ins, and applets.
Starting with an application, the common characteristics are that:
On the other hand, a plug-in’s characteristics are that:
And then we have the Java applet. Is it a “small application,” or is it something else? A Java applet
Whereas applications and plug-ins must be ported to each hardware platform, applets run on any platform that has a Java runtime. Thus, applets provide an object-oriented, multiplatform environment for the development of applications.