пропозиції роботи
Wypowiedzi
-
Witam wszystkich Rekruterów / Headhunterów :)
Aktualnie poszukuję dodatkowej pracy, którą mógłbym pogodzić z obecnym pełnoetatowym zatrudnieniem (pn-pt 9-17), przy czym nie wykluczam pracy we wspomnianych godzinach poza siedzibą przyszłego pracodawcy.
Chętnie wezmę udział w ciekawym projekcie IT w roli analityka, projektanta lub programisty bazodanowego.
Świetnie radzę sobie w środowisku bazodanowym MSSQL, podczas kariery zawodowej poznałem zarówno dobre, jak i złe praktyki budowania baz danych oraz tworzenia zapytań. Uczestniczyłem również przy tworzeniu projektów w oparciu o technologię C# (zarówno w roli programisty, jak i projektanta).
Tworzenie dokumentacji technicznej (zarówno opisów formalnych, specyfikacji, instrukcji obsługi, scenariuszy testowych) nie stanowi dla mnie problemu, a wręcz sprawia swojego rodzaju satysfakcję.
UML doceniam i wykorzystuję w stopniu "rozsądnym" - diagramy przypadków użycia, klas oraz maszyny stanowej +aktywności traktuję jako podstawę, pozostałe wykorzystuję w zależności od realnej potrzeby.
Przydatną wiedzą może okazać się znajomość rynku ubezpieczeń, w tym z zakresu obsługi IT sprzedaży polis, konstruowania taryf, analizy rynku ubezpieczeniowego (szkodowość, sprzedaż, wnioskowanie i analiza uzyskanych danych) oraz innych.
Jestem otwarty na nowe wyzwania, nowe projekty. Do pracy podchodzę sumiennie, zgodnie z założonymi wytycznymi przedsiębiorstwa (w tym ISO), lub poprzez wdrożenie własnej bazy wiedzy ukierunkowanej na konkretne zadania.
Rekomendowaną formą zatrudnienia jest umowa o pracę, zlecenie lub dzieło (nie posiadam własnej działalności gospodarczej).
Jeśli kogoś zainteresowała mój profil, proszę napisać, chętnie odpowiem na przekazane oferty.
Pozdrawiam serdecznie- 3.01.2014, 01:30
-
Tomasz M.:
private const int SW_SHOWNA = 4;
[System.Runtime.InteropServices.DllImport("user32.dll")]
private static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);
private void ShowWindowFromTray()
{
ShowWindow(this.Handle, SW_SHOWNA);
}
http://stackoverflow.com/questions/16493108/c-sharp-fo...
Trochę późno odpisuję, ale dokładnie o to mi chodziło! Bardzo dziękuję za pomoc :)
Sebastian O.:
oczekujesz gotowca ?
nie OCZEKUJĘ, liczę na pomoc i owszem, wierzę że ktoś w swojej karierze spotkał się z tym problemem choć raz. Ze stack'a i source forge'a (via google) korzystam regularnie, jednak całkiem szczerze nie bardzo wiedziałem jak doprecyzować zapytanie w tym przypadku.
A przy okazji offtopując na chwilę, życzę kolegom szczęśliwego nowego 0x7DE roku :) -
Witam,
Mam nietypowe zapotrzebowanie :)
Stworzyłem malutką aplikację (win foms), posiadającą atrybut topMost=true, opacity=0.5; (na wierzchu przed innymi oknami), jednak chciałbym, aby uruchomienie aplikacji nie "aktywowało" jej na "wierzch" (tzn aby zachowywała się podobnie jak np "chmurka" z podpowiedziami).
Scenariusz:
1. użytkownik pisze maila do klienta
2. podczas pisania, w wyniku odpowiedniej akcji, uruchomiona zostaje wspomniana aplikacja (wyświetla się na wierzchu)
3. Pomimo uruchomienia aplikacji która jest widoczna przed wszystkimi oknami, użytkownik nie musi przełączać okien (np alt+tab), aby wrócić do czynności, które wcześniej realizował
Ewentualnie może macie inne propozycje rozwiązania? Z góry dziękuję za pomoc :) -
Mikołaj W.:
Bardzo ciekawa dyskusja jako offtopic :D1. Niska cena = niski czas lub brak (!) testów.
Z tym nie do końca mogę się zgodzić, aczkolwiek wszystko zależy od podejścia firmy i zespołu (zarówno IT, jak i użytkowników), oraz samego rodzaju wykonywanych testów.
1. Analiza zagadnienia (faza analizy/projektu) - na tym etapie należy znaleźć możliwie jak najwięcej błędów. Wykonanie tego etapu zależy w dużej mierze od klienta, a projektant powinien pomóc w ich odnalezieniu. Kluczowe zatem jest częste zadanie pytań "a co jeśli...", "czy będzie miało to wpływ na..." oraz innych z kategorii -> pozwoli to wyeliminować część późniejszych nieprzewidzianych niespodzianek, często nazywanych błędem aplikacji;
2. Testy podczas developmentu: siłą rzeczy już tutaj programista/zespół programistów wykonuje stosowne testy podczas samego etapu uruchomienia wdrożenia, co prawda często na zasadzie "działa/nie kompiluje się", ale jednak :)
3. Testy akceptacyjne: jeśli coś nie działa, lub nie jest zgodne z założeniami specyfikacji projektu, zostaje cofnięte i nie przechodzimy do wdrożenia --> projekt wraca do poprawki. Zignorowanie tego punktu, to błąd ze strony klienta (niedokładne przeprowadzenie testów, niekorzystna umowa, etc).
4. Testy powdrożeniowe (choćby "dymne") - pozwala uniknąć "klapy" po uruchomieniu na środowisku produkcyjnym.
W moim odczuciu, niezależnie od ceny projektu, siłą rzeczy są wykonywane testy (ewentualnie może nie spotkałem się jeszcze z programistą, który po kompilacji nie wykonał nawet krótkiej weryfikacji działania, pomijając już scenariusze testowe).
Kryterium ceny ma znaczenie i owszem. ale cena nie jest głównym wyznacznikiem jakości projektu (zgodnie ze złotą zasadą "klient nie może zapłacić za projekt więcej niż sam posiada") i niezależnie od tego, czy za projekt X zapłacimy 100'000 PLN, czy 1'000'000 EUR, może coś być "zwalone" w mniejszym lub większym stopniu :)
Problem wielu firm, to nieprzewidywanie możliwych konsekwencji upraszczania lub koncentrowania się na "tu i teraz" (np "tego nie będziemy tak rozbudowywać, bo nie ma teraz takiej potrzeby"). I tak na przykład brak uogólnionego (lub po prostu brak) systemu kolejkowania komunikatów będzie skutkowało tym, że wcześniej czy później taki powstanie. Z drugiej strony permanentne uogólnienie projektu = "Znamy wasze potrzeby, stworzymy, ale jest na rynku gotowy produkt: Visual Studio" :)
Podsumowując: przy projektach IT nie powinniśmy mówić o "niskiej/wysokiej cenie" ale o stosunku ceny do jakości, a projekt powinien spełniać oczekiwania klienta.
Zamawiając pizzę (projekt IT) peperoni z ekstra serem , niezależnie od pizzerii (developera) i ceny, otrzymamy pizzę, będzie miała ekstra ser i peperoni (zgodność ze specyfikacją).
Nawet jeśli zapłacimy za nią 5zł a będzie zimna (działa zdecydowanie za wolno na produkcji) lub brakuje peperoni (nie spełnia wymagań specyfikacji) możemy jej nie przyjmować.
Jednak jeśli spełnia oczekiwania (jest pizzą, ma peperoni i ser i jest ciepła), ale nam nie smakuje: cóż, wina leży po naszej stronie - pizzeria wykonała swoją pracę zgodnie z założeniami :) -
Dziękuję za szczegółowe wskazówki dot. technologii, przejrzę i sprawdzę, co najlepiej mi odpowiada.
Sama idea skorzystania z tego typu narzędzi, to poniekąd chwilowe "lenistwo" - projekt jest na prawdę luźny, elementów DB do obsłużenia całkiem sporo, a założony czas iście krótki :) Większość rzeczy mam już i tak oprogramowanych z poziomu DB.
Adrian O.:
PS: polecam zastanowienie się, czy na pewno podejście "od bazy danych do kodu" będzie OK. Osobiście preferuję "code-first", chyba, że muszę się "wpiąć" w gotową bazę. Odwykłem już od podejścia "database-centric"...
Tutaj wg mnie wszystko zależy od wielkości projektu.
Na początku również trzymałem się dość kurczowo code-first'a (budując bardzo minimalistycznie bazę danych, często bez wnikania w CRUD'y nawet :) ).
Problem pojawia się w chwili, kiedy budowany jest spory system, często pojawiają się mniejsze lub większe zmiany. Jeśli oprzemy 3/4 funkcjonalności o aplikację, często można zyskać odrobinę na wydajności. Niestety pojawienie się jakiejkolwiek modyfikacji wymaga kompilacji, co często przy środowiskach o wysokim SLA generuje nieprzyjemną konieczność zostawania po pracy z powodu wgrania aktualizacji i/lub testów :) Ponadto Code-First w niektórych przypadkach może skutkować nie do końca przemyślanym projektem bazy danych, lub późniejszą modyfikacją samego kodu (dodatkowy czas=koszt), a już prawdziwym złem niedobrym (czasami niestety stosowanym) jest tworzenie zapytań SQL bezpośrednio po stronie aplikacji... Zdarzają się również modyfikacje systemu, których założenia trzeba po krótkim czasie modyfikować, czasami wracając do stanu sprzed zmiany (niezależnie od tego, jak dobrze wspomniane założenia zostaną określone).
Przy DB-first, jeśli mówimy o aplikacjach bardziej bazodanowych niż coś-mielących-potworach algorytmicznych :), zyskujemy pole manewru w postaci bezpośredniej modyfikacji db, szybkiego wdrażania nowych funkcjonalności (oczywiście tych, które można rozwiązać po stronie bazy danych), oraz łatwiejsze możliwości tuningu db. Jest pełno przydatnych narzędzi dla projektantów, które ułatwiają wdrożenie baz danych "w zgodzie ze sztuką" (np SSMS Tools).
Nawet czasami spotkałem się kilkukrotnie z przechowywaniem odpowiednich procedur wraz z wymaganymi parametrami bezpośrednio w bazie - może wydawać się dziwne, ale często jest to na prawdę fajne rozwiązanie z punktu widzenia późniejszej obsługi i administracji systemem.
Oczywiście nie krytykuję code-first, nie faworyzuję również db-first. Wszystko zależy od potrzeby: jeśli aplikacja/system, tudzież baza danych (jeśli istnieje) będzie modyfikowany raz na ruski rok, CF spisze się rewelacyjnie. Z mojego, może nie aż tak wieloletniego doświadczenia wiem jednak, że stworzony w ciągu około roku system będzie jeszcze przez ładnych kilka lat modyfikowany: dostosowywany, rozbudowywany, optymalizowany pod względem wydajności, etc :) W takim wariancie db-first pozwoli zaoszczędzić czasu, a poprawnie stworzony model sprawi, że stworzona aplikacja będzie niemal bezobsługowa dla programisty (w skrajnych przypadkach, przy hardkorowym podejściu do db-first, aplikacja może stać się wręcz "terminalem" do połączenia z bazą) :) -
Witam,
W pewnym etapie życia pomyślałem o poznaniu rozwiązania LINQ to SQL (na chwilę obecną moja wiedza jest bardzo ograniczona w tym zakresie, do tej pory wszystko budowałem "na piechotę").
O ile samo rozwiązanie wygląda na prawdę przyjemnie, nie znam jego mechanizmów działania (mówię o budowaniu struktur danych).
Planuję stworzyć aplikację ("gruby klient"), która będzie łączyła się z serwerem DB. Stworzę dwa środowiska: dev i prod (2 różne źródła danych).
Co może się stać, jeśli produkcyjna baza danych nie będzie zsynchronizowana z testową (np inne kolumny, nowe/brak tabel, inne procedury, etc)?
Czy sama zmiana źródła danych powinna zadziałać, czy może coś się posypać?
Czy rozwiązanie Linq nadaje się do użycia przy takim rozwiązaniu? Może są jakieś alternatywy :)
Generalnie zależy mi na otrzymaniu gotowych klas z odpowiednimi metodami, w oparciu o strukturę bazy danych; może znacie jakiś "generator kodu", który z automatu zbuduje mi odpowiednie klasy na podstawie założonej struktury DB? -
Witam,
Jestem absolwentem Warszawskiej Wyższej Szkoły Informatyki (inż). Aktualnie pracuję głównie w roli analityka, ze sporą domieszką projektanta/programisty bazodanowego oraz, może trochę na dokładkę - programisty .NET.
Obecnie można powiedzieć, że .NET jest bardziej moim hobby, aczkolwiek nadal tworzę nowe mniejsze lub większe aplikacje czy systemy.
Największe zboczenie: porównania, analizy biznesowe, wnioskowanie, algorytmika, optymalizacja :) -
Cóż, co robić, jak żyć? :) wszystkim dziękuję za pomoc w poszukiwaniach.
Wielka szkoda, że nie można zwracać własnych typów tab (a przynajmniej bez jakiegoś kombinowania na około).
Korzyści wg mnie byłoby sporo (oczywiście jeśli podejdziemy do takich bytów jak do "tablic", czegoś "pod ręką" zależnego od konkretnego wiersza).
Do tego ciekawym (acz ryzykownym) elementem byłoby tworzenie tabel tymczasowych, które jako jedną kolumnę posiadałyby właśnie nasz typ tabelaryczny - z takim rozszerzaniem można sobie poradzić oczywiście za pomocą XML'a, a wspomniana propozycja zapewne grubo wykracza poza ANSI SQL :) Uważam, że innowacja w postaci dodania array'a lub listy w określonych przypadkach byłaby fajna (np przechowywanie adresów e-mail w jednym miejscu, zamiast w osobnej relacyjnej tabeli), gdyby jeszcze posiadały odpowiednie metody (np getvalue(int index), Length; etc)... taki dodatkowy wymiar :) -
Marek K.:
Ale może warto zajrzeć do podstaw. W dokumentacji MSDN wyraźnie jest wskazane, że "Syntaktycznie funkcję można odróżnić od procedury tym, iż wymusza ona zadeklarowanie typu zwracanego jako wyniku przetwarzanego zapytania w jej ciele." więc z definicji nie działa to tak jak założyłeś.
Wiem i właśnie chcę zadeklarować zwracany własny typ tabelaryczny (a nie TABLE) na wyjściu funkcji.
W tym kontekście może jednak warto przemyśleć uwagę Sebastiana, bo wydaje się, że dobrze podpowiada bo
"dobre praktyki programowania w T-SQL nakazują, aby wykorzystywać procedury do operacji zapisu, modyfikacji, usuwania rekordów z bazy danych (czyli akcji, które nie zwracają konkretnych wartości), zaś funkcji - do przeprowadzania operacji matematyczno-analitycznych takich jak: liczenie średniej, dodawanie kolumn typu INT, przeliczanie wartości itp."
Dobre praktyki również znam, wiem do czego służy funkcja...natomiast skoro T-SQL oferuje funkcje zwracające TABLE-VALUED, to czemu nie mógłbym z tego skorzystać, ale z góry nakładając własny typ?
Czemu TABLE-VALUED FN są fajne i praktyczne? Jeśli musielibyśmy zbudować kilka różnych funkcji, które zwrócą różne wyniki (przykładowo jakieś złożone sumowanie, jakaś inna suma, jakiś status) przy użyciu tych samych danych (np 3 JOIN'y), a wierszy gdzie musielibyśmy użyć 3 funkcji jest >100'000, zamiast tego możemy za jednym zamachem zwrócić 3 różne wartości z odpowiednim użyciem CROSS APPLY.
I w tym przypadku potrzebuję swojego typu tabelarycznego nie do wyświetlenia danych, tylko dopiero do dalszego uzyskania właściwego wyniku (stale korzystając z tego samego, przefiltrowanego źródła danych).
Czyli:
1. Potrzebna funkcja, która zwróci tabelę i zapisze do zadeklarowanej zmiennej
2. Silnie rekomendowane zastąpienie (w funkcji) TABLE moim własnym typem tabelarycznym --> to jest to, co mi się do tej pory nie udało, więc na razie "jadę" na RETURNS TABLE -
Damian L.:
Emilu w funkcjach można używać typów zdefiniowanych przez użytkownika.
Jedyny wyjątek to ten, o którym napisałem. Typy tabelaryczne mogą być używane pod warunkiem, że używasz ich jako parametrów wejściowych tylko do odczytu. Musisz chyba rozwiązać problem inaczej tak jak zasugerował to Sebastian Olszewski :)
Przykład na stronie widziałem, ale niestety odnosi się do procedury. Z funkcją już kombinowałem chyba na wszystkie możliwe sposoby (zarówno budując funkcję a'la "scalar" i "table-valued").
przykład na szybko:
CREATE TYPE dbo.testmojtyptab as TABLE(kol1 int)
CREATE FUNCTION dbo.test()
returns dbo.testmojtyptab --READOLNY /*też próbowałem, wtedy błąd przy READONLY*/
as
begin
declare @a dbo.testmojtyptab
insert into @a
select 1
return @a
end
--zwraca Must declare the scalar variable "@a". -
Damian L.:
Wydaje mi się, że się nie da.
http://msdn.microsoft.com/en-us/library/bb510489.aspx
Table-valued parameters must be passed as input READONLY parameters to Transact-SQL routines. You cannot perform DML operations such as UPDATE, DELETE, or INSERT on a table-valued parameter in the body of a routine.
Jako parametr wejściowy i owszem, nawet wydaje się logiczne :) Natomiast właśnie dlatego zamiast procedury zawierającej parametr wyjściowy chcę stworzyć funkcję z odpowiednim wyjściem -
Sebastian O.:
Napisz jak chcesz tego użyć, bo może jest łatwiejszy sposób rozwiązania Twego problemu.
Czy funkcja może, oprócz typów systemowych (INT, NVARCHAR, TABLE, etc) zwracać zdefiniowane przez użytkownika typy (np utworzony typ tabelaryczny dbo.tmpusers).
Czyli
CREATE FUNCTION zwrocmojtyp()
RETURNS @ret mojtyptabelaryczny
Tak jak napisałem: można zabezpieczyć się poniekąd przed ingerencją w zwracany typ, jeśli w środku określimy sobie, jak w środku ma wyglądać nasza tabela, ale już przy RETURNS, jesli ma to być tabela, muszę podać jego dokładną strukturę ręcznie
Najlepiej zobrazuje to poniższy przykład:
--tworzymy typ
create type dbo.mojtyptab as table
(
id int, name nvarchar(50)
)
GO
--tworzymy funkcję zgodną ze strukturą naszego typu
create function dbo.fntabletest()
returns @a table
(
id int,
name nvarchar(50)
)
as
begin
insert into @a values (1,'test')
insert into @a values (2, 'test')
return
end
GO
--test: wszystko ok, mieliśmy farta
declare @demo dbo.mojtyptab
insert into @demo
select * from dbo.fntabletest()
select * from @demo
GO
--teraz zmiana procedury
alter function dbo.fntabletest()
returns @a table
(
id int,
name nvarchar(10),--zmiana długości kolumny!
age int --nowa kolumna
)
as
begin
insert into @a values (1,'test',10)
insert into @a values (2, 'test',20)
return
end
GO
--...i próbujemy zrobic to samo przy naszym niezmienionym typie
declare @demo2 dbo.mojtyptab
insert into @demo2
select * from dbo.fntabletest() --> błąd, nie zgadza się liczba kolumn
--sprzątamy po demo
drop function dbo.fntabletest
drop type dbo.mojtyptab -
Trochę leciwy przykład http://technet.microsoft.com/en-us/library/aa214485%28...
Widziałem ten przykład i w podobny sposób rozwiązałem problem, tzn:
tworzę zmienną określonego typu tabelarycznego, później klasyczny insert
DECLARE @u dbo.tmpusers
INSERT INTO @u (userid, name)
SELECT * FROM dbo.fn_getuserlist(1)
Gdzie fn_getuserlist (@param int) returns TABLE
Później oczywiście jakaś procedura z @param dbo.tmpusers READONLY
Oczywiście działa, natomiast przy takim modelu niestety nie mam większej kontroli nad tym, co zostanie przekazane przez funkcję, np jeśli ktoś zmieni tabelę zwracaną przez fn, wtedy kaplica :)
Gdybym mógł zwracać parametr własnego typu (zamiast TABLE), wtedy mam z góry nałożoną strukturę i nie zachodzi ryzyko, że coś się posypie (czyli nie panuję nad tym, jaką strukturę zwróci fn_getUserList() ); w tym przypadku TABLE jest nazbyt ogólne
Trochę tak, jakbym w C# próbował przekazać obiekt typu object parsowany na int do zmiennej typu int - rosyjska ruletka :) -
Witam,
Chciałbym utworzyć funkcję, która zwróci mi zdefiniowany typ tabeli.
przykładowo:
stworzyłem odpowiedni typ tabeli:
CREATE TYPE dbo.tmpusers TABLE
(
userid int,
name nvarchar(100)
)
W odpowiedniej procedurze mam utworzony obiekt nowego typu:
DECLARE @a dbo.tmpusers
Teraz zamiast klasycznego dodawania do @a za pomocą inserta:
INSERT INTO @a (userid, name)
SELECT 1, 'test'
chciałbym stworzyć funkcję, która będzie pobierała 1 parametr (np int) i zwróci mi obiekt typu dbo.tmpusers
a'la:
CREATE FUNCTION dbo.fn_getUsers (@status int)
RETURNS dbo.tmpusers
as
BEGIN
declare @a dbo.tmpusers
INSERT INTO @a (userid, name)
SELECT 1, 'test'
return @a
END
Niestety to nie działa... Może ktoś wie, jak sobie z tym poradzić (tzn stworzyć funkcję, która zwróci zdefiniowany obiekt typu tabelarycznego)? -
Ok, chyba znalazłem rozwiązanie (być może przyda się komuś):
Edytowałem connectionstring, dopisując na końcu przy Extended Properties:
IMEX=1
np:
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=XXXXXXXXXXXXXXX.xls;Extended Properties="EXCEL 8.0;HDR=YES;IMEX=1";
na razie widzę, że NULL'e ładnie zastąpiły się poprawnymi wartościami, ale muszę jeszcze o tym poczytać dokładnie.
Dziękuję za wskazówkę. -
To by się nawet nieszczęśliwie zgadzało (dokładnie 8 pierwszych pustych wartości w komórkach). sytuacja jest skrajna, ale się zdarza...
Teoretycznie w zaawansowanym edytorze, przy kolumnie wyjściowej ustawiłem odpowiedni typ, ale wnioskuję, że SSIS robi sobie z tym, co mu się podoba i moje sugestie ignoruje...
Czy można ewentualnie zmienić wspomniane "rozpoznanie" z 8 do max liczby prób? (są to stosunkowo małe importy, więc mogę sobie pozwolić na wydłużenie czasu)? A może istnieje jakaś sztuczka, którą można to obejść (wszystko niestety muszę zamieścić wewnątrz samej paczki, nie mogę ingerować w dane źródłowe - kluczowa jest kolejność importowanych rekordów)? -
Witam,
Spotkałem się z bardzo specyficznym przypadkiem: posiadam pewien szablon w excelu, który regularnie importuję za pomocą skonstruowanej paczki SSIS (VS 2005).
Podczas ostatniego importu zauważyłem, że jedna kolumna zawierająca datę:
format: 2013-10-25 12:00:11
albo pusta (NULL).
Zauważyłem, że podczas importu ostatniej paczki, przy kolumnie z datą, zaciągnęły się wszędzie NULL'e, pomimo wprowadzonej, poprawnej wartości daty, sam szablon również nie uległ zmianie.
Zweryfikowałem Excel źródłowy i wszystko wygląda w porządku, nawet na wszelki wypadek od początku utworzyłem nowe źródło, ale nawet przy podglądzie pojawiają się te nieszczęsne NULL'e. w SSIS kolumna jest typu wręcz Unicode string [DT_WSTR] , zatem walidacja daty nie powinna wchodzić w grę (z datą też próbowałem już).
Co ciekawe: W excelu źródłowym, przez kilka pierwszych wierszy przewija się pusta wartość w kolumnie z datą. W chwili, kiedy usunąłem pierwsze pozycje, przy podglądzie w SSIS pojawiły się już poprawne wartości...
Czy SSIS jakoś pseudointeligentnie, jeśli pojawi się kilka rekordów z NULL'em na początku uznaje, że cała kolumna jest NULL'em? Czy ktoś spotkał się może z omawianym problemem?
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
