Raspberry PI with Serial Cable notes
ls /dev/tty.*
then
screen -L /dev/tty.PL2303-00001014 115200
ls /dev/tty.*
then
screen -L /dev/tty.PL2303-00001014 115200
I ran into a little difficulty today with the default behavior of the playlist in jwPlayer and the position=”over” configuration. After some simple digging into the code under PlaylistComponent.as which is in the namespace com.longtailvideo.jwplayer.view.components I found that the behavior is controlled by this snippet of code. This is for jwPlayer version 5.9.x
Func<string,bool> IsPalindrome=str=>{for(var i=0;i<str.Length;i++){if(str[i]!=str[str.Length-1-i])return false;}return true;};
Using a recursive function can be very expensive as you’re stack will get larger and larger as you need to store in memory a pointer to the last function on top of the current function.
The other thing that can happen is that using a standard integer in .NET can only hold up to a certain amount of numbers. The below example, handles both scenarios.
1: void Main()
2: {
3: fib(5);
4: }
5:
6: void fib(int size)
7: {
8: var fibArray = new System.Numerics.BigInteger[size];
9:
10: fibArray[0] = 1;
11: fibArray[1] = 1;
12:
13: for (var i = 2; i < size; i++)
14: fibArray[i] = fibArray[i-2] + fibArray[i-1];
15:
16: for (var i = 0; i < size; i++) fibArray[i].Dump();
17:
18: }
So after playing with my own code after a while I realized that there was a slight flaw in my thinking. Since every application is slightly different in the way it determines what culture to use, and that each request is technically a different Thread, I need a more generic way to capture that information.
I decided to use a querystring value. Here is my updated code in regards to reading the querystring culture, setting it and fired up the appropriate ResourceManager..
ResourceManager rm = new ResourceManager(ConfigurationManager.AppSettings["JSResourcesAssemblyType"].ToString(),
Assembly.LoadFile(ConfigurationManager.AppSettings["JSResourcesAssemblyPath"].ToString()));
if (context.Request.QueryString["CultureCode"] == null) return;
var culture = context.Request.QueryString["CultureCode"].ToString();
ResourceSet rs = rm.GetResourceSet(new CultureInfo(culture), true, true);
var sbInitial = "var rm = {";
var sb = new StringBuilder(sbInitial);
var resEnum = rs.GetEnumerator();
while (resEnum.MoveNext())
{
if (sb.ToString() != sbInitial) sb.Append(",");
sb.Append(""" + resEnum.Key + "":"" +
resEnum.Value.ToString().Replace("rn", "").Replace(""", "\"") + """);
}
sb.Append("}");
sb.ToString();
context.Response.ContentType = "text/javascript";
context.Response.Write(sb.ToString());
This is actually quite a useful solution. The goal here is to use the same resource file for client and server side coding, while also utilizing the “Culture” awareness of .NET that might be built into your application.
Be sure to create your Resources as a separate satellite assembly.
We are going to create an HttpHandler. Basically create a class and implement the IHttpHandler interface.
Look at the sample code below.
public class ResourceJS : IHttpHandler
{
public bool IsReusable
{
get { return true; }
}
public void ProcessRequest(HttpContext context)
{
ResourceManager rm = new ResourceManager(ConfigurationManager.AppSettings["JSResourcesAssemblyType"].ToString(),
Assembly.LoadFile(ConfigurationManager.AppSettings["JSResourcesAssemblyPath"].ToString()));
rm.GetString("");
ResourceSet rs = rm.GetResourceSet(Thread.CurrentThread.CurrentCulture, false, false);
var sbInitial = "var rm = {";
var sb = new StringBuilder(sbInitial);
var resEnum = rs.GetEnumerator();
while (resEnum.MoveNext())
{
if (sb.ToString() != sbInitial) sb.Append(",");
sb.Append(""" + resEnum.Key + "":"" +
resEnum.Value.ToString().Replace("rn", "").Replace(""", "\"") + """);
}
sb.Append("}");
sb.ToString();
context.Response.ContentType = "text/javascript";
context.Response.Write(sb.ToString());
}
}
You can see here that there are two Web.config values that have specified here. JSResourcesAssemblyType is the full Namespace and root class name of the Resource files. JSResourcesAssemblyPath is the location of satellite assembly. This uses reflection to load up the metadata of the assembly.
Once this compiled, you need to add this to the web.config. Here is a sample for IIS7.
<handlers>
<remove name="WebServiceHandlerFactory-Integrated" />
<remove name="ScriptHandlerFactory" />
<remove name="ScriptHandlerFactoryAppServices" />
<remove name="ScriptResource" />
<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add name="ResourceJS" path="ResourceJS.axd" verb="GET" type="ResourceJS" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode" />
<add name="UrlRoutingHandler" preCondition="integratedMode" verb="*" path="UrlRouting.axd" type="System.Web.HttpForbiddenHandler, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</handlers>
You can see the ResourceJS is being extended to the url ResourceJS.axd. Below is my sample page.
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="ResourceJSTest.aspx.cs" Inherits="ResourceJSTest" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
<script type="text/javascript" src="js/2.1.0.0-debug/jquery-1.4.4.min.js"></script>
<script type="text/javascript" src="/ResourceJS.axd"></script>
<script type="text/javascript">
$(function () {
$("#target").html(rm.FAQ_Q8_TEXT);
});
</script>
</head>
<body>
<form id="form1" runat="server">
<div id="target"></div>
</form>
</body>
</html>
The rm object in javascript has all the “keys” that were defined in the original RESX file for that culture. You can call any of these as a property of rm. Very re-usable.
There are several cases where you would want to break down your view into several small components. One use case that I am working with right now, is I have a multi-lingual site that I would like to reload content using AJAX principles.
Normally what I would do in the case of a non-multi lingual site is to create another ActionResult to return the ViewModel that is changing with the new parameters. I like to use a custom ActionResult that I have called JsonpResult. The problem resides in the fact that I have labels not in my database but in Resource files. So what I would need to do is to somehow hydrate my Resource file data into the ViewModel.
Once the data comes down the pipe, my AJAX callback handles the wiring up of the ViewModel response back to the HTML page using Javascript (I use jQuery).
This definitely works, however it becomes a question of maintainability. I now need to not only maintain my original ASP.NET view, but I also need to maintain a set of scripts that handle AJAXian behavior. If you need to have your site SEO, then you really need to make sure that both the Server Side and Client Side behavior are both working the same.
This is where Partial Views come into play for me. What I do is "pull out" the logical data sections where the bulk of the reload occurs. The nice thing about PartialView is that you can pass your ViewData and Model along to the PartialView. If your PartialView is strongly typed against your ViewModel you can get Intellisense to help with the wiring of the PartialView.
Now all I need to do with my AJAX call is to write the response back to a single DIV rather than handling data points individually. What it does mean is that there would be more content coming down the pipe. However, the trade off is easier to read and maintain code.