Friday, 10 August 2018

HTTP 404 Not Found Error with woff or woff2 Font Files

 For woff and woff2 fonts we get these below errors. I was getting for my Product  QFLES

  • HTTP/1.1 404 Not Found
  • Failed to load resource: the server responded with a status of 404 (Not Found)
even files are present in the directory.

Cause

On many server configurations, the WOFF or WOFF2 file is not expected.  The default configuration for most web servers is to deny a request for any unexpected file type, including this one.  This is why you see the HTTP 404 response, even though the file exists.

Fix

You simply need to update your web.config file to tell the web server (IIS) that this file is okay to serve, and how to serve it.  Use your preferred or available method to edit the web.config file, including the built-in Configuration Manager module.
Find the <system.webServer> section in your web.config, and look to see if it already has a <staticContent> section.  If it doesn't create it.  Otherwise, you'll be editing it now.
In the example you see below, the <staticContent> section likely didn't exist already, and it was added to the top of the <system.webServer> section, but before the <modules> section.  In your site, you don't need to have this exact placement.  Just make sure that the <staticContent> section is found somewhere between the open and close <system.webServer> tags.
  <system.webServer>
    <staticContent>
      <clientCache cacheControlCustom="public" cacheControlMode="UseMaxAge" cacheControlMaxAge="365.00:00:00" />
   <remove fileExtension=".woff" />
      <remove fileExtension=".woff2" />
      <mimeMap fileExtension=".woff" mimeType="application/x-font-woff" />
      <mimeMap fileExtension=".woff2" mimeType="application/font-woff2" />
    </staticContent>
    <modules>
The important parts of the example above are the <remove> and <mimeMap> tags for your font files.  If you already have a <staticContent> section added, make sure those lines are added in your configuration file.

Monday, 6 August 2018

QFLES - Students can post their Learning Needs and Tutors can find Students here

Hello Guys,

We are providing a Platform (QFLES) that will bridge the gap between Tutors/Institutes and Students/Learners.

Students or You can post their learning requirements for thousands of categories like Tuition, IT Courses, IT Course Computer Software,Sports,Beauty and Style, Business, Clinical, Cooking, Dance, Engineering Subject, Exam Coaching,Foreign Education Exam Coaching,Government Exams Coaching, Medical, Fashion, Film and Media, Finance, Health and Fitness, Functional, General, Health and Fitness,Hobby, Instrumental Music and more. Post Your Learning Need!

Parents can also find near by Private Tutors and Coaching Centers for their Children.

Other Side Tutors/Institutes can find Students and get hired by them. It's very easy way EARN and LEARN strategy. Register Here!

Thanks
QFLES Team

Wednesday, 31 January 2018

Choose between an interface and abstract class


Choose between an interface and abstract class?
I have been asking this question in interviews for some years now. I get to hear a lot of interesting answers from folks. All these answers have helped me make a great addition to my knowledge. If you google this topic you would find a lot of interesting articles. This article on MSDN offers a good discussion on the topic. To summarise the recommendations from there and few other articles I have come across, here are the reasons in favour of abstract classes

Use abstract class if you have a default implementation of some behaviour that child classes do not have to implement
Prefer abstract classes if your contract has a possibility of changing over time. So if you are using an abstract class and need to add a new method to your abstract class, you can happily add that without breaking any code using that class. The same is not true for interfaces.


And these are the reasons in favour of interfaces
Since multiple inheritance is not supported in C#, you cannot inherit your class from two abstract classes. An interface is your only option in such situations.
If there is no default or common behaviour among all the classes that are inheriting from abstract class then interface may be a better choice.


I personally do not believe that these give a complete picture.
What is wrong with this reasoning?


First, above recommendations are mostly around syntax a particular language supports and not around semantics (e.g. use interfaces if you need multiple inheritance). By semantics I mean, what definition of an interface fundamentally differentiates it from an abstract class?


Second, I feel the above criteria are too futuristic. By that I mean, they all depend on you knowing how your design is going to take shape in future. At times, I may have some idea of how my design is going to take shape in future but most of the times I do not have enough clarity to know in advance
Whether I am going to need to inherit from multiple abstract classes or not
Whether there is going to be a default implementation of some contract or not
Whether I would add a new method to a contract or define a new contract entirely in order to implement a change


So, if you do not know which way your software is going to go, there is no way you can base your decision of interface or abstract class on these reasons.
So how do we decide?


Lately, I have been using below heuristic to determine when to use interfaces/abstract classes and I feel quite excited about it as it works most of the time.


Interfaces represent capabilities and abstract classes represent type


in other words


Implementing interfaces represents can-do relationship and inheriting from (abstract) class represents an is-a relationship


To elaborate this point, let’s consider following two classes


public class Camera


{


public void Shoot()


{


//Take a picture here


}


}


public class Gun


{


public void Shoot()


{


//Hit the target


}


}



Both Camera and Gun can Shoot, that is their capability. But they are both not the same type of things, they are completely different. So an interface like below would make more sense here


public interface IShootable


{


void Shoot();


}


public class Camera : IShootable


{


public void Shoot()


{


//Take a picture here


}


}


public class Gun : IShootable


{


public void Shoot()


{


//Hit the target


}


}



If you have learned OO programming the same way I did, then you would remember the classic shape example as below


public abstract class Shape


{


void Draw();


}


public class Rectangle : Shape


{


public void Draw()


{


//Draw a rectangle here


}


}


public class Circle : Shape


{


public void Draw()


{


//Draw a circle here


}


}



Rectangle and Circle inheriting from Shape makes perfect sense here because Rectangle/Circle are a type of Shape.