Rozwiązaniem jest zrobienie własnego filtru oraz użycie gadgetu „Filter results”.

Żeby to zrobić, najpierw definiujemy filtr. Wybieramy zakładkę „Issues”, a potem tryb wyszukiwania „Advanced”. Do okienka wpisujemy:

Zapisujemy filtr jako „Watched and unresolved”.

Na dashboardzie możemy teraz dodać gadget „Filter results”, gdzie jako źródło zadań wybierzemy nasz nowy filtr.

Babol 1 , Babol 2

Aj… Szkoda. Nawet zczubacy się poddali:

„No i po wszystkim. Arsenal ma jeszcze szansę na własnym boisku, musi tylko szybko znaleźć jakiegoś bramkarza.”

Invalid memory access of location 00000010 eip=901a277b

Odrobina googlowania podsunęła rozwiązanie: http://code.google.com/p/google-web-toolkit/issues/detail?id=4220#c22

1. Należy ściągnąć aktualny build WebKit pod MacOS stąd: http://nightly.webkit.org/
2. Otworzyć dwuklikająć plik .dmg, przeciągnąć WebKit do /Applications/
3. W Eclipse wybrać Run -> Run Configurations z menu.
4. Po lewej stronie wybrać naszą aplikację (pod Web Applications)
5. Wybrać zakłądkę „Environment”
6. Dodać zmienną:
   Name: DYLD_FRAMEWORK_PATH
   Value: /Applications/WebKit.app/Contents/Frameworks/10.5
7. Zapisać

Problem powinien być rozwiązany.

http://www.ted.com/talks/devdutt_pattanaik.html

Ułatwiłoby to logowanie wszystkiego, co zachodzi w aplikacji. Wywołując metodę:

public void CountPrice(int bar, string baz)
{

}

chciałbym otrzymać w logach wpis:

Method’s Foo arguments >> bar: 1, baz: zzz

Najpierw spróbowałem za pomocą metody GetParameters klasy MethodInfo. Zwrócone obiekty typu ParameterInfo zawierają jednak tylko informacje o typach parametrów – nie mają wartości tych parametrów w czasie wykonywania kodu.

Moim celem było stworzenie metody, którą mógłbym użyć do pobrania sformatowanej informacji o parametrach metody – na przykład w celu zalogowania ich. Załóżmy dla prostoty testowania, że nasza metoda Foo będzie zwracała sformatowany napis z jej parametrami i ich wartościami.

Pierwsza wersja:

public class TestClass
{
  public static string Foo(int bar, string baz)
  {
    return LogingHelpers.GetMethodArguments();
  }
}

public class LoggingHelpers
{
  public static string GetMethodArguments()
  {
    //TODO tutaj magia :-)
    return "";
  }
}

Niestety – z taką składnią nie udało mi się. Z kontekstu LoggingHelpers.GetMethodArguments nie da się (lub nadal nie potrafię :-) ) dostać się do parametrów metody wywołującej. Działająca składnia jest nieco inna i odrobinę mniej wygodna:

public class TestClass
{
  public static string Foo(int bar, string baz)
  {
    return GetMethodArguments(() => bar, () => baz);
  }

  public static string NoParameters()
  {
    return GetMethodArguments();
  }
}

public class LoggingHelpers
{
  public static string GetMethodArguments(params Func<object>[] expr)
  {
    //TODO tutaj magia, ujawnione już za chwilę!
    return "";
  }
}

Ale najpierw test z wykorzystaniem NUnit.

    using NUnit.Framework;
    using NUnit.Framework.SyntaxHelpers;

    [TestFixture]
    public class LoggingTests
    {

        [Test]
        public void TwoParametersCorrectlyFormatted
        {
            string parameterNamesAndValues = TestClass.Foo(1, "zzz");
            Assert.That(parameterNamesAndValues, Is.EqualTo("Method's Foo arguments >> bar: 1, baz: zzz");
        }

        [Test]
        public void NoParametersCorrectlyFormatted
        {
            string noParameters = TestClass.NoParameters();
            Assert.That(noParameters, Is.EqualTo("Method's Foo arguments >> No arguments.");
        }
    }

Odpalamy testy, który oczywiście nie przechodzą.

Żeby testy zadziałały, nasza klasa LoggingHelpers wraz z metodą GetMethodParameters może wyglądać tak:

using System;
using System.Diagnostics;
using System.Reflection;
using System.Runtime.CompilerServices;

public class LoggingHelpers
{
    public static string GetMethodParameters(params Func<object>[] expr)
    {
      // Pobieramy nazwę metody.
      string methodname = new StackFrame(1).GetMethod().Name;

      // wstępne formatowanie wynikowego napisu:
      string logmessage = "Method's " + methodname + " arguments >> ";

      // Tablica wyrażeń lambda jest pusta
      if (expr.Length == 0)
      {
        logmessage += "No arguments.";
      }
      else
      {
        try
        {
          // dla każdego Expression
          foreach (var par in expr)
          {
            // Zaawansowane sztuczki. Za pomocą MSIL znajdujemy informacje o Expression
            byte[] il = par.Method.GetMethodBody().GetILAsByteArray();

            // bajty 2-6 oznaczają uchwyt do naszych parametrów
            int fieldHandle = BitConverter.ToInt32(il, 2);

            // pobieramy FieldInfo tego parametru
            FieldInfo field = par.Target.GetType().Module.ResolveField(fieldHandle);

            // Formatujemy ostatecznie napis dla tego parametru.
            // Nazwę parametru uzyskujemy z FieldInfo, natomiast wartość wykonując przekazane Expression.
            logmessage += string.Format("{0}: {1}. ", field.Name, par() ?? "@null");
          }
        }
        catch
        {
        // Ignorujemy błędy - nic nie jest gorsze od doskonale działającej logiki aplikacji, która wywala się na narzędziach do logowania :-)
        // Tego typu try-catch to zła praktyka w aplikacji! W tym miejscu jest to stosowne, ale przestrzegam przed nadużywaniem "zjadania" wyjątków.

          logmessage += " FAILED reading arguments.";
        }
      }
    }
}

Klasa do wykorzystania w aplikacji.

W kolejnej notce pokażę, jak to spiąć z log4net.

Ciekawe, jakie są teraz na to kursy u bukmacherów.

Ich dzieło wspólne to właśnie Stack Overflow. System reputacji i nagród za zadawanie mądrych pytań i dawanie pomocnych odpowiedzi świetnie działa – moje trzy pytania na dosyć niszowe tematy prawie natychmiastowo miały odpowiedzi, za to trudno było znaleźć pytanie bez odpowiedzi.

Znalazłem tam masę zbiorów różnego rodzaju sztuczek programistycznych. Dzisiaj lista najciekawszych .NET-owych pytań. To także dosyć dobry materiał do przygotowywania się do testów podczas rekrutacji na wymarzone stanowisko programisty.

• „Ukryte” funkcje języka C#. – Padają tam podstawowe rzeczy np. „yield” lub „using”, ale wiele z nich nie znałem, a teraz wykorzystuję samemu.
• Najbardziej przydatne atrybuty. – Niestety mało kto używa atrybutów z frameworka, a co dopiero wykorzystuje własne w swoim kodzie. System.Obsolete to mój ulubiony ułatwiający refaktoryzację.
• Najbardziej zadziwiające zachowania języka – często spotykane na rozmowach kwalifikacyjnych. Nie cierpię pytań o tego typu szczegóły, ponieważ często ma się ona nijak do naszych umiejętności. Niemniej jednak lepiej zabłysnąć taką wiedzą, nawet jeżeli jej nigdy nie wykorzystamy.
• Zbiór metod rozszerzających – Wątek rewelacja. Mnóstwo świetnych metod rozszerzających, bardzo polecam. Autorzy nawet zrobili z tego gotową bibliotekę.
• Na jakie pytania każdy programista .NET powinien umieć odpowiedzieć? – kolekcja pytań na rozmowy o pracę i do wykorzystania nacodzień.
• Częste pomyłki – każdy programista .NET powinien się z tą listą zapoznać, często zdarza mi się widzieć kod, który podpada pod rzeczy wymienione w tym wątku.
• Najbardziej przydatne darmowe biblioteki do .NET – doskonały zbiór open source narzędzi. Używam wiele z nich – NHibernate, RhinoMocks, log4net, StructureMap, itd. Od nadmiaru wymienionych narzędzi może rozboleć głowa, ale każde jest opatrzone komentarzem, co ułatwia nam decyzję, czego użyć
• Co możemy zrobić w MSIL, czego nie zrobimy w C#. – bardziej zaawansowany temat wykorzystania samego MSIL (języka pośredniego, assemblera .NET) zamiast C#. Możemy sobie nawet zrobić przeładowane metody, które różnią się tylko typem zwracanym. Nawet nie wiem jak by to działało. :-)

Polecam przeglądanie Stack Overflow samemu, baza wiedzy i pomocnych osób jest imponująca.

kliknij w tytuły żeby otworzyć iTunes

Run!

Prosta, arcade’owa gierka polegająca na unikaniu przeszkód. Dosyć trudna i mocno wciągająca. Świetnie wykorzystuje interfejs dodytkowy – skok to machnięcie do góry, wślizg machnięcie w dół, itd. Mój rekord to 1501. Najlepsi na świecie osiągają ponad 2500 punktów – trochę nie ogarniam, jak to możliwe. :)

Cena: 0,79 €.

California Gold Rush

Kopanie złota w ładnej oprawie graficznej.

Cena: 0,79 €.

Dungeon Hunter

Zagrywam się w to od kilku dni. Klon Diablo na iPhona. Wydana przez Gameloft – producenta gier z najlepszą grafiką w Appstore.

Cena: 5,49 €.

The Secret of Monkey Island

Klasyczna przygodówka powraca w wersji na iPhona. Nieźle się uśmiałem przy dialogach, nie mogę się doczekać kolejnych części.

Cena: 5,99 €.

Doodle Jump

Bardzo prosta i grywalna gierka w grafice „doodle” (nie wiem jaki jest polski odpowiednik). Skaczemy na kolejne platformy, po drodze strzelając do potworków i UFO. Często wychodzą kolejne wersje z nowymi ficzersami.

Cena: 0,79 €.

A Doodle Flight

Klasyczna strzelanka samolotem. Grafika taka jak w Doodle Jump. Możemy sobie narysować własny stateczek. :-) Naprawdę trudna na wyższych poziomach trudności. Kropka jako pojazd niestety mało pomaga.

Cena: 0,79 €.

StoneLoops of Jurassica

iPhonowy klon Zumy. Rewelacja, szczególnie dla fanów oryginału.

Cena: 0,79 €.

Alive 4-ever

Mroczny survival shooter.

Cena: 1,59 €.

Minigore

Kolejny survival shooter, tym razem w kreskówkowej grafice. Dosyć prosta, ale są zapowiedziane kolejne wersje.

Cena: 0,79 €.

Knights Onrush

Castle defense. Celem gry jest obrona zamku przed hordami rycerzy, maszyn oblężniczych i olbrzymów. Bronimy podrzucając atakujących w powietrze lub używając różnych power ups z zamku. Dosyć szybko się nudzi, co nie przeszkodziło mi grać w to kilka dni.

Cena: 0,79 €.