Skocz do zawartości

BREWNESS.com - startup dla piwowarów domowych


brewness

Rekomendowane odpowiedzi

@@brewness

1) Powracam z moją propozycją odnośnie sortowania według kolumn, jest szansa na jej realizację? Kiedy?

2) Druga sprawa to podawanie koloru piwa - podajecie kolor ziarna wg EBC a kolor piwa wg SRM. Czy nie moglibyście tego ujednolicić i obok koloru piwa w SRM podawać też w EBC?

3) trzecia wreszcie sprawa - w kolumnach jest nazwa, gęstość, rozmiar, styl, ibu, srm - dodajcie również abv aby od razu było wiadomo jaką "moc" ma dane piwo z przepisu co dla niektórych jest ważne gdy szukają lekkiego bądź sesyjnego piwa w danym stylu.

Z góry dzięki.

 

Punkty 1 i 3 zostały zrobione na początku miesiąca, niestety nie miałem jak wcześniej tego zakomunikować bo byłem na urlopie ;)

 

Pozdrawiam

Odnośnik do komentarza
Udostępnij na innych stronach

 

 

Pozdrawiam


Kolejna propozycja - w sekcji dodatki dajcie możliwość wyboru między wagą a objętością, czasami trzeba dodać ileś tam soku czy innego płynu i wtedy bardzo by się to przydało.
Odnośnik do komentarza
Udostępnij na innych stronach

  • 2 tygodnie później...

Rozpocząłem warzyć 3 piwa naraz i dla każdego otworzyłem nową kartę poprzez "uwarz to". Po zapisaniu wszystkich 3 okazało się, że mam 2 warki z tym samym numerkiem.

 

Faktycznie tak mogło się zdarzyć, możesz wrócić do pierwszego kroku i zmienić numer ręcznie. Poprawimy to.

Odnośnik do komentarza
Udostępnij na innych stronach

  • 1 miesiąc temu...
  • 4 tygodnie później...
  • 4 miesiące temu...

Aha... :D

Sypnąłem odrobinę cukru więcej niż było w recepturze, ale może 30g. Pewnie też sypnęło mi się więcej słodu.

 

edit: Ale jak w przepisie ustawię wydajność 100% i objętość taką jak mi wyszła to przewidywana gęstość to 20.7blg a to co uzyskałem to 16.8. 16.8 jest przy wydajności 77%, jednak nie jestem aż tak wydajny ;)

 

Przy okazji: jeśli w przepisie jest cukier, to nie lepiej jako gęstość przed gotowaniem wyświetlać gęstość bez cukru, albo obie?

Edytowane przez koval_blazej
Odnośnik do komentarza
Udostępnij na innych stronach

  • 4 tygodnie później...

Tak jak pisałem wyżej, wydajności 100 % to tam nie ma.

Na stronie https://brewness.com/pl/batch/10053/view teraz widać 92.4% (chyba dalej za dużo?), ale jak wejść w edycję na zakładkę "Fermentacja burzliwa", dalej nie pokazuje wydajności.

Odnośnik do komentarza
Udostępnij na innych stronach

  • 2 miesiące temu...
Dnia 8.05.2018 o 19:09, Igorrodz napisał:

Nie widzę stylu "Norwegian Farmhouse Ale", dlaczego?
@brewness Czy moglibyście go dodać?

Jasne, zapisałem to do zrobienia.

 

Dnia 22.02.2018 o 08:37, koval_blazej napisał:

Tak jak pisałem wyżej, wydajności 100 % to tam nie ma.

Na stronie https://brewness.com/pl/batch/10053/view teraz widać 92.4% (chyba dalej za dużo?), ale jak wejść w edycję na zakładkę "Fermentacja burzliwa", dalej nie pokazuje wydajności.

Przepraszam Cię bardzo, że dopiero teraz odpisuję ale nie dostałem żadnego powiadomienia... rzucę okiem na tą warkę i dam znać.

Odnośnik do komentarza
Udostępnij na innych stronach

Przejrzałem ten wątek, ale mam problem ze zrozumieniem, jak liczycie straty. Przykład:

  • oczekiwana ilość gotowego piwa: 22l
  • czas gotowania: 60min
  • szybkość odparowywania: 10%/h
  • straty z gotowania: 10%
  • straty z fermentacji: 5%
  • straty z chmielenia na zimno: 0%

Obliczacie, że ilość gotowanej brzeczki to 27,8l. Zatem sprawdzam:

  • zaczynam od 27,8l
  • po godzinie gotowania mam 27,8l * 90% = 25,020l
  • po przelaniu do fermentora mam 25,020l * 90% = 22,518l
  • po fermentacji zostaje mi na rozlew 22,518l * 95% = 21,392l

Brakuje mi 0,6l piwa. To na podstawie mojej receptury bittera. Sprawdziłem dla dwóch innych -- występuje podobna odchyłka.

Edytowane przez vmario
Odnośnik do komentarza
Udostępnij na innych stronach

No dobra, rozgryzłem te straty. Wbiłem 10l piwa, straty z gotowania 100%/h, pozostałe na 0%. Na zdrowy rozum aplikacja powinna mnie zbesztać, że w 60 minut cała brzeczka mi wyparuje, ale ona twierdzi, że z 20l brzeczki zrobi 10l piwa przy stratach 100%/h...

 

Obliczenia Brewness wyglądają tak: 10l * 100% = 10l strat, więc trzeba 10l + 10l = 20l brzeczki.

 

Właśnie komuś anulowano maturę z matematyki. Jak uważacie, mnie, czy programiście z Brewness?

Odnośnik do komentarza
Udostępnij na innych stronach

 

26 minut temu, vmario napisał:

No dobra, rozgryzłem te straty. Wbiłem 10l piwa, straty z gotowania 100%/h, pozostałe na 0%. Na zdrowy rozum aplikacja powinna mnie zbesztać, że w 60 minut cała brzeczka mi wyparuje, ale ona twierdzi, że z 20l brzeczki zrobi 10l piwa przy stratach 100%/h...

 

Obliczenia Brewness wyglądają tak: 10l * 100% = 10l strat, więc trzeba 10l + 10l = 20l brzeczki.

 

Właśnie komuś anulowano maturę z matematyki. Jak uważacie, mnie, czy programiście z Brewness?

Okej, przy takich stratach wiadomo, że wyjdą bzdury, zablokuję możliwość wpisania 100%, co i tak nie zmienia faktu, że "testujesz" warunki brzegowe. 

Sposób wyliczania strat był przez te kilka lat istnienia projektu konsultowany z wieloma piwowarami, jeśli masz jakiś pomysł na ich udoskonalenie to zapraszam na priv.

 

14 godzin temu, wannabuydrugs napisał:

Wiadomo już kiedy będzie zaktualizowana aplikacja na telefon?

Aplikacja mobilna będzie rozwijana, na razie szukamy źródła finansowania, to obecnie jedynie nas blokuje.

Odnośnik do komentarza
Udostępnij na innych stronach

29 minutes ago, brewness said:

Okej, przy takich stratach wiadomo, że wyjdą bzdury, zablokuję możliwość wpisania 100%, co i tak nie zmienia faktu, że "testujesz" warunki brzegowe.

Podstawą testowania jest wprowadzanie wartości brzegowych. Zablokowanie 100%/h nic nie zmieni. Odnieś się do wcześniejszego postu, gdzie straty wynoszą 10%/h i widać, że wychodzi źle. Możesz też wziąć sobie inny prosty przykład: 50l piwa, straty 10%/h. Aplikacja podaje 55l brzeczki. Skoro odparowuje 10% brzeczki na godzinę, to po 60 minutach zostanie 55l - 55l * 10% = 49,5l, bo program liczy tak: 50l + 50l * 10% = 55l, a powinien tak: 50l / (100% - 10%) = 50l / 90% = 55,6l. Wówczas mamy 55,6l - 55,6l * 10% = 50l. Jasne, różnica jest niewielka, ot, jedna butelka przy bardzo dużej warce (chyba że dodamy kolejne rodzaje strat -- błąd się wtedy kumuluje), stąd nikt tego nie wyłapał. W praktyce to są wartości niezauważalne, ale wystarczy poprawić jedną linijkę w aplikacji, a nie iść w zaparte.

Edytowane przez vmario
Odnośnik do komentarza
Udostępnij na innych stronach

1 minutę temu, vmario napisał:

Podstawą testowania jest wprowadzanie wartości brzegowych. Zablokowanie 100%/h nic nie zmieni. Odnieś się do wcześniejszego postu, gdzie straty wynoszą 10%/h i widać, że wychodzi źle. Możesz też wziąć sobie inny prosty przykład: 50l piwa, straty 10%/h. Aplikacja podaje 55l brzeczki. Skoro odparowuje 10% brzeczki na godzinę, to po 60 minutach zostanie 55l - 55l * 10% = 49,5l, bo program liczy tak: 50l + 50l * 10% = 55l, a powinien tak: 50l / (100% - 10%) = 50l / 90% = 55,6l. Wówczas mamy 55,6l - 55,6l * 10% = 50l. Jasne, różnica jest niewielka, ot, jedna butelka przy bardzo dużej warce, stąd nikt tego nie wyłapał. W praktyce to są wartości niezauważalne, ale wystarczy poprawić jedną linijkę w aplikacji, a nie iść w zaparte.

Ja nie twierdzę, że to źle, że testujesz warunki brzegowe, po prostu nikt tak nie używa tego softu.

Tu nie chodzi o to, żeby iść w zaparte ;) jakbyś prześledził ile zmian od userów wprowadzaliśmy to byś zrozumiał, że nie mamy takiego podejścia. Chodziło mi o przykład, takowy podałeś, więc chętnie się nad tym zastanowimy. Już poza wszystkim to odparowanie powinno być wartością bezwzględną, mamy to na liście do zrobienia ale niestety zawsze jest coś ważniejszego i to dalej wisi :/ 

Odnośnik do komentarza
Udostępnij na innych stronach

Jak już się czepiać, to podając parowanie w % początkowej objętości na godzinę, to tak naprawdę powinniśmy to całkować po czasie!

A tak naprawdę naprawdę to przecież parowanie zależy od powierzchni a nie objętości, więc podawanie go w procentach tak czy siak nie będzie miało wiele sensu.

Odnośnik do komentarza
Udostępnij na innych stronach

Teraz, koval_blazej napisał:

Jak już się czepiać, to podając parowanie w % początkowej objętości na godzinę, to tak naprawdę powinniśmy to całkować po czasie!

A tak naprawdę naprawdę to przecież parowanie zależy od powierzchni a nie objętości, więc podawanie go w procentach tak czy siak nie będzie miało wiele sensu.

Dlatego właśnie będzie to niebawem wartością bezwzględną :) 

Odnośnik do komentarza
Udostępnij na innych stronach

On 5/17/2018 at 10:58 PM, brewness said:

Tu nie chodzi o to, żeby iść w zaparte ;) jakbyś prześledził ile zmian od userów wprowadzaliśmy to byś zrozumiał, że nie mamy takiego podejścia.

Tak to odebrałem, bo zamiast wykazać mi błąd w obliczeniach, napisałeś, że nie mam racji, bo przecież wszyscy są zadowoleni. A jeżeli dla dużych wartości (niepraktycznych, ale fizycznie dopuszczalnych) nie da się udawać, że błędu nie ma, to należy zawężyć zakres wejściowy i gotowe.

Oczywiście, nie chcę tą całą dyskusją o jednym błędzie deprecjonować całej aplikacji, bo używam jej już rok i jest to naprawdę kawał dobrej roboty! Dopiero w ostatnim czasie brak pewnych funkcji skłonił mnie do pracy nad własnym arkuszem kalkulacyjnym i dobrze zdaję sobie sprawę, ile to jest pracy.

18 hours ago, koval_blazej said:

Jak już się czepiać, to podając parowanie w % początkowej objętości na godzinę, to tak naprawdę powinniśmy to całkować po czasie!

A tak naprawdę naprawdę to przecież parowanie zależy od powierzchni a nie objętości, więc podawanie go w procentach tak czy siak nie będzie miało wiele sensu.

Rzecz w tym, że ten błąd dotyczy nie tylko strat z odparowania, ale też wszystkich pozostałych. Poza tym to jest błąd w implementacji prostego modelu, którego nadmierna komplikacja niczemu nie służy.

Edytowane przez vmario
Odnośnik do komentarza
Udostępnij na innych stronach

Teraz, vmario napisał:

Tak to odebrałem, bo zamiast wykazać mi błąd w obliczeniach, napisałeś, że nie mam racji, bo przecież wszyscy są zadowoleni. A jeżeli dla dużych wartości (niepraktycznych, ale fizycznie dopuszczalnych) nie da się udawać, że błędu nie ma, to należy zawężyć zakres wejściowy i gotowe.

Oczywiście, nie chcę tą całą dyskusją o jednym błędzie deprecjonować całej aplikacji, bo używam jej już rok i jest to naprawdę kawał dobrej roboty! Dopiero w ostatnim czasie brak pewnych funkcji skłonił mnie do pracy nad własnym arkuszem kalkulacyjnym i dobrze zdaję sobie sprawę, ile to jest pracy.

Rzecz w tym, że ten błąd dotyczy nie tylko strat z odparowania, ale też wszystkich pozostałych. Poza tym to jest błąd w implementacji prostego modelu, które nadmierna komplikacja niczemu nie służy.

Jeśli tak to odebrałeś to sorry, nie taka była moja intencja :) Napisz proszę jakich funkcji brakuje to chętnie przemyślimy ich dodanie, bo skoro Tobie czegoś brakuje to może inni też chętnie z tego skorzystają ;)

Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Umieściliśmy na Twoim urządzeniu pliki cookie, aby pomóc Ci usprawnić przeglądanie strony. Możesz dostosować ustawienia plików cookie, w przeciwnym wypadku zakładamy, że wyrażasz na to zgodę.