Localization is crucial for reaching out to a global audience, however, it’s often an afterthought for most developers and non-trivial to implement. Traditionally, game developers have outsourced this task due to its time consuming nature.

But it doesn’t have to be this way.

Yan Cui will show you a simple technique his team used at GameSys which allowed them to localize an entire story-driven, episodic MMORPG (with over 5000 items and 1500 quests) in under an hour of work and 50 lines of code, with the help of PostSharp.

Watch the webinar and learn:

  • The common practices of localization
  • The challenges and problems with these common practices
  • How to rethink the localization problem as an automatable implementation pattern
  • Pattern automation using PostSharp

Solving localization challenges with design pattern automation on Vimeo.

You can find the slide deck here: http://www.slideshare.net/sharpcrafters/solving-localization-challenges-with-design-pattern-automation

 

About the speaker, Yan Cui

Yan Cui

Yan Cui is a Server Architect Developer at Yubl and a regular speaker at code camps and conferences around the world, including NDC, QCon, Code Mesh or Build Stuff. Day-to-day, Yan has worked primarily in a mixture of C# and F#, but has also built some components in Erlang. He's a passionate coder and takes great pride in writing clean, well structured code.
Yan's blog.

 

When addressing website performance issues, developers typically jump to conclusions, focusing on the perceived causes rather than uncovering the real causes through research.

Mitchel Sellers will show you how to approach website performance issues with a level of consistency that ensures they're properly identified and resolved so you'll avoid jumping to conclusions in the future.

Watch the webinar to learn:

  • What aspects of website performance are commonly overlooked

  • What metrics & standards are needed to validate performance

  • What tools & tips are helpful in assisting with diagnostics

  • Where you can find additional resources and learning

Applying a methodical approach to website performance on Vimeo.

You can find the slide deck here: http://www.slideshare.net/sharpcrafters/applying-a-methodical-approach-to-website-performance

Q&A

Q: Are there any specific tools that we can use to load test APIs?

A: Google PageSpeed Insights works only for public facing stuff. YSlow as a browser plugin will work on any page including authenticated, unauthenticated, or public facing so that might be a good choice.

Q: What is a normal/acceptable request per second (RPS) for a CMS site?

A: The acceptable number really depends on the hardware. From my experience with working with DotNetNuke content management system on an Azure A1 server, we start to see failures at about 102 - 105 requests per second. However, it really varies and will depend on what your application is doing (number of requests, number of static files it has, etc.). While there's not necessarily a gold standard, if you see anything under 100, it's typically a sign of an application configuration or other issue rather than the fact that you do not have a large enough hardware.

 

 

About the speaker, Mitchel Sellers

Mitchel Sellers

Mitchel Sellers is a Microsoft C# MVP, ASPInsider and CEO of IowaComputerGurus Inc, focused on custom app solutions built upon the Microsoft .NET Technology stack with an emphasis on web technologies. Mitchel is a prolific public speaker, presenting topics at user groups and conferences globally, and the author of "Professional DotNetNuke Module Programming" and co-author of "Visual Studio 2010 & .NET 4.0 Six-in-One".
Mitchel's blog.

 

 

We’re excited to announce the first public preview of PostSharp 5.0, available for download from our website and from NuGet Gallery (make sure to enable pre-releases). Starting from today, we’re going to update the preview every third week.

In this blog post, I would like to focus on the most demanded feature that is already present in the current preview: Support for .NET Core 1.0 (CLI).

After so many unsuccessful platforms pushed by Microsoft during the last years (I’m thinking of you, Windows Phone), it’s good to see real customer demand for .NET Core. Some corporate customers already see .NET Core as a successor to Java, captured in the hands of the evil Oracle. We’re excited to see some real enthusiasm (not just marketing-driven hype) for the initiative.

TL;DR

PostSharp 5.0 has partial and unfinished support for .NET Core 1.0.

To add PostSharp to your .NET Core projects, follow the procedure described in this KB article.

Limitations

However it’s a real challenge for us to support this platform, so we have split the effort into several phases. Our objective with PostSharp 5.0 is to build on Windows, run everywhere. Today, we’re releasing the first bits. However, the work is still in progress, and you will see more features appear in the next previews.

The following NuGet packages have already been ported to .NET Core 1.0:

  • PostSharp
  • PostSharp.Patterns.Common
  • PostSharp.Patterns.Diagnostics
  • PostSharp.Patterns.Diagnostics.Console
  • PostSharp.Patterns.Diagnostics.AspNetCoreLogging

A few notes and disclaimers: it is not clear yet whether PostSharp 5.0 RTM will support .NET Core 1.0 or .NET Core 1.1 with its new build system based on MSBuild and CSProj. We will take the decision once the roadmap of .NET Core 1.1 will be clearer. Keep in mind that we may drop support for .NET Core 1.0 before PostSharp 5.0 reaches RTM.

Note that we’re prioritizing our work according to the needs of our commercial customers. If you’re a commercial customer and interested in .NET Core, please reach out to our technical support and express your priorities.

Splitting of Tools and Redistributable Packages

More and more customers are using NuGet as an internal vehicle to distribute binaries across different development teams. They use an internal repository, to which the continuous integration system automatically uploads successful builds. Many of these customers have requested a way to express a run-time dependency on PostSharp without necessarily including PostSharp in the build process. You may have of course the same requirements if you want to upload to the public NuGet Gallery a package built with PostSharp, but which can be referenced without requiring the referencing project to be enhanced by PostSharp.

For this scenarios, it became necessary to split all packages into a run-time part and a build-time part. Furthermore, .NET Core requires build-time tools and run-time dependencies to be packaged separately.

Therefore, we decided to split all packages into two parts: one package with the run-time assets, and another package with the build-time assets.

Although the most popular convention seems to be for the build-time package to have the BuildTools suffix, we decided otherwise in order to maintain backward compatibility. We will be following another popular convention, where the build-time package will be unsuffixed, and the run-time package will have the Redist suffix. (Note that the current preview has the Redistributable suffix. This will be changed in the next preview.)

We’ve already split the PostSharp package in two parts. In the next previews, we will continue and split all relevant packages.

Summary

We’ve done good progress in supporting .NET Core 1.0 and will do more during the next weeks. Feedback? Questions? Don’t hesitate to share them as comments to this blog post.

Happy PostSharping!

-gael