This is a mirror of official site: http://jasper-net.blogspot.com/

How To Run Ubuntu Linux On Samsung Galaxy S III

| Saturday, June 23, 2012
The Galaxy S III is making some serious inroads with development that seems to be speeding up with every step. The latest big news to hit SGS3 users is Ubuntu and Backtrack Linux beeing booted onto the device. Honestly, I don’t personally see the point of using Linux on an Android device, but if it’s Android and you’re a true geek, having the option and being actually able to pull it off, is a feat on its own. As for the procedure, we have XDA-Developers forum member tiborri to thank for jotting up a tutorial, and of course, a few pieces of the tutorials have actually been borrowed from other tutorials. So if you have patience and are familiar with executing scripts, read on after the break to learn more about how you can get Linux running on your Galaxy S III.

All images below are courtesy of tiborr.

To start off, you will be needing an app called, Ubuntu Installer developed by zackthespack. This app once launched, will allow you to download and install 3 more apps that are required to get Ubuntu up and running on the device:

VNC Viewer
Android Terminal Emulator
Busybox
Needless to say your device needs to be rooted for this app to function properly. If you haven’t already done so, view our rooting guide for the Galaxy S III here. That done, to avoid any issues, install the Omega 5 ROM featured here. Make sure USB debugging is enabled on the device. Now run the app and download the Ubuntu file.

You will now need to run a script that was originally written by zacthespack (download). Once this is downloaded, copy this script (ubuntu.sh) and the ubuntu file downloaded via Ubuntu Installer onto the internal memory of the phone in a folder named Ubuntu.

With all the data in its place, you now need to run the Android Terminal, and enter the following commands:

su

cd /sdcard/ubuntu

sh ubuntu.sh

Read more: Addictive tips

Posted via email from Jasper-net

Android FeelUX

| Thursday, June 21, 2012
Inline image 1

As one of the leading handset manufacturers in Japan, Sharp recognized the need to address an expanding market of smartphone users. After conducting surveys in Japan and the US, the company wanted to create new Android handsets that would stand out in a crowded field and attract first-time buyers while catering to the needs of current Android customers.

Redefining the Android Mobile UI Paradigm

According to Google statistics, an estimated 850,000 devices are activated every day across the world, making Android the most popular smartphone platform. However, while many customers favor the platform’s openness, flexibility and diverse choice of handsets, an overload of branded phones without clear product differentiation can make selecting an Android device overwhelming. The traditional Android model had some fundamental usability issues, and an entirely fresh approach was the only solution to create a meaningful experience.
Sharp collaborated with frog’s team of designers and technologists to design a new mobile user-experience model, called “Feel UX”, that is uncluttered and effortless to organize and use. Unlike other handset manufacturers who historically customize Android by simply adding another layer on top of the platform, the frog team carefully curated the experience to create a new device that is straightforward for beginner Android users, yet has the flexibility in customization that advanced users love.

Read more: frog
QR: Inline image 2

Posted via email from Jasper-net

OpenNebula

|
About the OpenNebula.org Project

Mission

OpenNebula.org is an open-source project developing the industry standard solution for building and managing virtualized enterprise data centers and cloud infrastructures.

Vision

IaaS Cloud Computing is the next step in the evolution of the data center. Because no two data centers are the same, we do not think there's a one-size-fits-all in the cloud, and we do not try to provide a turnkey solution that imposes requirements on data center infrastructure. OpenNebula interoperability makes cloud an evolution by leveraging existing IT infrastructure, protecting your investments, and avoiding vendor lock-in. In contrast to other open-source management tools that only provide a special-purpose implementation of popular cloud interfaces on pre-defined environments, OpenNebula aims to provide a open, flexible, extensible, and comprehensive management layer to automate and orchestrate the operation of virtualized data centers by leveraging and integrating existing deployed solutions for networking, storage, virtualization, monitoring or user management.

Objectives

The OpenNebula.org project pursues the following objectives in order to lead innovation in enterprise-class cloud data center management:

Develop the most-advanced, highly-scalable and adaptable solution for building and managing virtualized data centers and cloud infrastructures
Assure the stability and quality of the software distribution
Collaborate with the most demanding users of cloud and data center management tools
Spread awareness of the Project
Support the ecosystem of open-source components being created around the Project
Support the community of users and developers contributing to the Project
Collaborate with other open-source projects and communities
Collaborate with the main research projects in cloud computing innovation
Core Values

The core values of the OpenNebula.org project are:

Openness of the processes and the technology
Excellence for being a project of the highest quality in every aspect of its operations
Cooperation with open-source efforts and research projects to advance cloud computing
Innovation in new technologies and methods to address needs of large-scale cloud deployments

Read more: OpenNebula
QR: Inline image 1

Posted via email from Jasper-net

ConfigSource attribute on system.serviceModel section

| Wednesday, June 20, 2012
The configSource attribute was firstly introduced in .NET framework 2.0 to support external configuration files.

This attribute can be added to any configuration section to specify a an external file for that section. Using an external configuration source can be useful in many scenarios. For instance, you could place a section into an external configSource if you need an easy method to swap settings for the section depending on the environment (development, test, or production), or  you need granular control over permissions.

Unfortunately, the system.serviceModel section group does not support this attribute. If you try to add it, you will receive the following exception:

The attribute 'configSource' cannot be specified because its name starts with the reserved prefix 'config' or 'lock'

What I found out is that you can use this attribute on the different sections under system.serviceModel such as services, behaviors or bindings.

For instance, the configuration file could look like this,

<configuration>
 
  <system.serviceModel>
    <services configSource="Services.config" >
    </services>
 
    <bindings configSource="Bindings.config">
    </bindings>
 
    <behaviors configSource="Behaviors.config">
    </behaviors>
 
  </system.serviceModel>
 
</configuration>
 And then, each file contains the corresponding section.

Services.config

<services>
  <service name="Microsoft.ServiceModel.Samples.CalculatorService"
          behaviorConfiguration="CalculatorServiceBehavior">
    <host>

QR: Inline image 1

Posted via email from Jasper-net

ExecutionContext vs SynchronizationContext

| Tuesday, June 19, 2012
’ve been asked a few times recently various questions about ExecutionContext and SynchronizationContext, for example what the differences are between them, what it means to “flow” them, and how they relate to the new async/await keywords in C# and Visual Basic.  I thought I’d try to tackle some of those questions here.

WARNING: This post goes deep into an advanced area of .NET that most developers never need to think about.

What is ExecutionContext, and what does it mean to flow it?

ExecutionContext is one of those things that the vast majority of developers never need to think about.  It’s kind of like air: it’s important that it’s there, but except at some crucial times (e.g. when something goes wrong with it), we don’t think about it being there.  ExecutionContext is actually just a container for other contexts.  Some of these other contexts are ancillary, while some are vital to the execution model of .NET, but they all follow the same philosophy I described for ExecutionContext: if you have to know they’re there, either you’re doing something super advanced, or something’s gone wrong.

ExecutionContext is all about “ambient” information, meaning that it stores data relevant to the current environment or “context” in which you’re running.  In many systems, such ambient information is maintained in thread-local storage (TLS), such as in a ThreadStatic field or in a ThreadLocal<T>.  In a synchronous world, such thread-local information is sufficient: everything’s happening on that one thread, and thus regardless of what stack frame you’re in on that thread, what function is being executed, and so forth, all code running on that thread can see and be influenced by data specific to that thread.  For example, one of the contexts contained by ExecutionContext is SecurityContext, which maintains information like the current “principal” and information about code access security (CAS) denies and permits.  Such information can be associated with the current thread, such that if one stack frame denies access to a certain permission and then calls into another method, that called method will still be subject to the denial set on the thread: when it tries to do something that needs that permission, the CLR will check the current thread’s denials to see if the operation is allowed, and it’ll find the data put there by the caller.

Things get more complicated when you move from a synchronous world to an asynchronous world.  All of a sudden, TLS becomes largely irrelevant.  In a synchronous world, if I do operation A, then operation B, and then operation C, all three of those operations happen on the same thread, and thus all three of those are subject to the ambient data stored on that thread. But in an asynchronous world, I might start A on one thread and have it complete on another, such that operation B may start or run on a different thread than A, and similarly such that C may start or run on a different thread than B.  This means that this ambient context we’ve come to rely on for controlling details of our execution is no longer viable, because TLS doesn’t “flow” across these async points.  Thread-local storage is specific to a thread, whereas these asynchronous operations aren’t tied to a specific thread.  There is, however, typically a logical flow of control, and we want this ambient data to flow with that control flow, such that the ambient data moves from one thread to another.  This is what ExecutionContext enables.

ExecutionContext is really just a state bag that can be used to capture all of this state from one thread and then restore it onto another thread while the logical flow of control continues.  ExecutionContext is captured with the static Capture method:

// ambient state captured into ec 
ExecutionContext ec = ExecutionContext.Capture();

and it’s restored during the invocation of a delegate via the static run method:

ExecutionContext.Run(ec, delegate 
    … // code here will see ec’s state as ambient 
}, null);

All of the methods in the .NET Framework that fork asynchronous work capture and restore ExecutionContext in a manner like this (that is, all except for those prefixed with the word “Unsafe,” which are unsafe because they explicitly do not flow ExecutionContext).  For example, when you use Task.Run, the call to Run captures the ExecutionContext from the invoking thread, storing that ExecutionContext instance into the Task object. When the delegate provided to Task.Run is later invoked as part of that Task’s execution, it’s done so via ExecutionContext.Run using the stored context.  This is true for Task.Run, for ThreadPool.QueueUserWorkItem, for Delegate.BeginInvoke, for Stream.BeginRead, for DispatcherSynchronizationContext.Post, and for any other async API you can think of.  All of them capture the ExecutionContext, store it, and then use the stored context later on during the invocation of some code.

Posted via email from Jasper-net

Projection in Windows 8

| Sunday, June 17, 2012
Inline image 1

בפוסט הקודם שעסק במה זה WinRT הזכרתי שאפשר לכתוב אפליקציות Metro במגוון שפות (C# & Xaml, C++ & Xaml, Js & HTML) ולעבוד מול ה-WinRT בצורה די שקופה. מי שמאפשר את זה היא ה-Language Projection.

 מה היא ה-Language Projection

WinRT היא חלק מה-Windows Core, היא fully native code, והיא חושפת APIs אשר מולם אנחנו יכולים לעבוד.

כיוון ש-WinRT צריכה לשרת כמה שפות (C#, C++, js), דרושה שכבת תיווך שתחשוף אותה בצורה המותאמת לאותה שפה, וזו שכבת ה-Projection אשר מעליה נמצאת האפליקציה שלנו.

 

אובייקט WinRT מממש 2 ממשקים חשובים:

IUnknown – כיוון ש-WinRT עובדת מעל COM, כל אובייקט צריך לממש את Iunknown, זה ממשק שהיה קיים עוד לפני WinRT, והוא מסמל אובייקט שאנחנו לא יודעים עליו כלום.
IInspectable – כל אובייקט WinRT מממש IInspectable, זה ממשק חדש שמאפשר לחקור את האובייקט דרך ה-MetaData שלו וזה מה ששכבת ה-Projection עושה.

 

MetaData

ה-MetaData נמצא בתוך קובץ WinMD (Windows Meta Data)

אפשר לפתוח אותו עם ILDASM ולראות מה הוא מכיל:

Read more: Windows 8
QR: Inline image 2

Posted via email from Jasper-net

תמונה אחת שווה אלף מילים: כיצד מנהלי מוצר יכולים לשתף את חזונם באמצעות Storyboarding של Visual Studio 2012

|
Inline image 1

התסריט הבא בהחלט לא דמיוני: מנהל המוצר הגדיר ביחד עם הלקוח את הדרישות, הצוות סיכם את ההבנות במסמך מפורט, וכעבור חצי שנה של עיצוב ופיתוח ,מוצגת ללקוח גרסה ראשונית של המוצר. "אבל לא כך התכוונתי שכך זה יראה" הלקוח מתעצבן וארשת של אכזבה עוטה את פניו.

ה- UI הוא שער הכניסה של המוצר שלנו, ולכן חשוב לשתף את הלקוח או השותפים שלנו בחזות שלו מוקדם כלל האפשר על מנת להקטין את האפשרות להפתעות הנובעות מהסובייקטיביות של הבנת הדרישות. אבל כיצד ניתן להציג את ה-UI עוד לפני שלב התכנון המוצר? ובכן, כלי ה-Storyboarding הכלול ב- 2012 Visutal Studio מאפשר בדיוק את זה.

יכולות ה- ALM של TFS מרחיבות את מעגל המשתתפים בתהליך הפיתוח ומאפשרים שיתוף פעולה בין הצוותים השונים על גבי פלטפורמה אחת אחודה. אם ב-Team System 2005 דיברנו על פלטפורמה אשר מיועדת בעיקר למפתחים, הרי שבגירסת 2008 הורחב המעגל למשתמשים מחוץ לצוותי הפיתוח עם ה-Team System Web Access , ובגירסת TFS 2010 הורחב המעגל לצוותי הבדיקות באמצעות ה-Test Manager. ב- VS 2012 שוב מרחיבים את המעגל וכוללים את מנהלי המוצר והמעצבים ונותנים להם כלי ייעודי בו יכלו לשתף את צוותי הפיתוח בחזונם.

כלי ה-Storyboarding הינו למעשה תוסף ל- PowerPoint, המאפשר ליצור אב-טיפוס של ה-UI תוך שימוש באלמנטים וקונטרולים של מערכת ההפעלה (גם PC וגם Mobile), אשר זמינים כחלק מגלריה עשירה של אלמנטים. כך באמצעות גרירה פשוטה של אלמנטים (בדומה לפעולה שנעשית ב-Visio) ניתן להגדיר את הממשק בצורה ברורה וחזותית. למעשה, עצם הבחירה בעבודה עם PowerPoint מאפשרת יתרונות רבים כמו זמינות, פשטות, וכמובן שיתוף בכלי ותיק ומוכר שמאפשר למשתמש היצירתי לחלוק את חזונו עם שותפיו.

התוצר הסופי משולב כחלק מתהליך הפיתוח (מקושר ל- User Story work item) ונותן רקע והקשר למשימות השונות. למשל, משימה לפיתוח קונטרול מסויים מקושרת לקובץ ppt של המסך הרלוונטי. המתכנת או המעצב מקבל תיאור מילולי של הדרישה בצירוף מקבץ תמונות שכותב הדרישה צירף וביתר קלות לממש אותה. וזאת ללא צורך ביכולת טכנית של כותב הדרישה. כמו כן, במהלך הפיתוח ניתן להשוות בין מה שפותח בפועל למה שתוכנן.

 

Storyboarding בתוך PowerPoint
כאמור ה-Storyboarding משולב כתוסף ל- PowerPoint. הוא מופיע בתפריט העליון כתפריט Storyboarding ותחתיו ribbon עם שלל אפשרויות.

QR: Inline image 2

Posted via email from Jasper-net

WCF on TCP : Keep your connections alive

|
I recently had a customer coming in with question and request on WCF connection pooling, which is very valid. I was almost convinced that answer to his question would be 'by design' but what worried me was if there is a solution for his predicament. To my pleasant surprise, mighty WCF team did think about the scenario and 'by design' there was a solution to his exact problem.

He is using net.tcp port sharing on the server for two different WCF services configured with net.tcp binding. The client code is such that proxy is created every time, service called and proxy closed. This sequence could be done for two services in any required combinations, lets say by calling Service 1() and Service2(). If Service1() is called repeatedly, TCP connection created in first call is pooled and reused. This is nice and as expected to save on connection establishment costs every time. But as soon as Service2() is called, TCP connection used for Service1() is reset. This sounds inappropriate. Seems, cost of port sharing is that pooled connection for Service1 has to be replaced with new connection to Service2. Very inefficient in an enterprise scenario where client makes random calls to Service1 and Service2 in volume as connection will be reset each time.

Whoever plays with TCP connection pooling is almost certain to stumble upon this: http://kennyw.com/work/indigo/173

Solution to my customer's predicament lies in this line taken from above link "Our connection pool is configurable through TcpConnectionPoolSettings/NamedPipeConnectionPoolSettings. These settings include a GroupName that we use for isolation"

You may think of it like this. TCP connection pool in WCF is identified with 'Port Number' and 'GroupName' (possibly more but only these are relevant for our purpose). If you omit 'GroupName', WCF provides a default. If you are not explicitly providing 'connectioPoolSettings', you are in effect omitting 'GroupName'. Since both the endpoints (for Service1 and Service2) use same port and have same 'GroupName' (Default), implies both endpoints will use same connection pool Id. When Service2 needs to be reached, its connection pool is already in place at client side but WCF infrastructure need to reset the connection to same port.

Use 'GroupName' to isolate connection pools for two endpoints and you can have connections alive when switching from Service1 to Service2 in there own respective pools.

This does mean that you will need to resort to custom binding but that’s an acceptable cost for such a huge benefit. A typical client config to achieve desired behaviour with net.tcp transport will look like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.serviceModel>
    <bindings>
      <customBinding>
        <binding name = "bindingA">
          <tcpTransport>
            <connectionPoolSettings groupName="connectionPoolA"/>
          </tcpTransport>

Read more: DistributedWorld
QR: Inline image 1

Posted via email from Jasper-net