Integracja aplikacji, najogólniej ujmując, jest procesem dostarczania zasobów lub możliwości z jednej aplikacji do drugiej. W miarę ewolucji świata aplikacji, integracja aplikacji jest oczekiwana w wielu kontekstach. Na przykład, jeśli kiedykolwiek używałeś poświadczeń Facebooka do zalogowania się do innej aplikacji, skorzystałeś z integracji aplikacji. Deweloper drugiej aplikacji oszczędził Ci kłopotów z dostarczaniem danych osobowych, integrując proces uwierzytelniania z Facebookiem.
Tworzenie aplikacji może nie tylko przynieść korzyści deweloperowi wykorzystującemu integrację aplikacji, ale można również utworzyć aplikację w taki sposób, aby można ją było zintegrować z innymi aplikacjami. Może to prowadzić do możliwości uzyskania przychodu lub zwiększenia zasięgu Twojej aplikacji lub platformy.
Prawie każda nowa aplikacja jest zazwyczaj połączeniem trzech ogólnych typów kodu: kodu źródłowego dostarczonego przez system operacyjny, kodu napisanego przez programistę, który jest specyficzny tylko dla tworzonej aplikacji, oraz kodu napisanego przez inne strony, które programista wykorzystuje w nowej aplikacji.
Kod zintegrowany z innych źródeł jest określany na różne sposoby, takie jak frameworki, biblioteki lub pakiety SDK (Software Development Kits). Chociaż istnieją różnice między tymi typami kodu, na potrzeby tego artykułu będziemy traktować je tak samo i używać terminu framework.
Framework to partia kodu, który żyje samodzielnie i jest kompilowany osobno. Jest napisany w konkretnym celu i zazwyczaj ma wąski zakres. Nowa aplikacja może nie integrować żadnych zewnętrznych struktur lub może wykorzystywać wiele. Opracowując projekt, twórca aplikacji rozważa, ile kodu musi napisać sam i ile będzie w stanie zintegrować.
Doświadczeni twórcy wiedzą jakie frameworki dostępne są aktualnie na rynku. Wiedzą, jak korzystać z istniejących frameworków w sposób, który przyniesie korzyść budowanej aplikacji – i kiedy tego nie robić. I wiedzą, jak zbudować swoją aplikację, aby jej części mogły stać się także częścią dla innych, jeśli jest taka potrzeba
Wiele frameworków jest dostarczanych przez Apple i Google. Na przykład dla rzeczy takich jak przyciski, pola i obrazy. Kodują i zachowują podstawowe zachowanie tych elementów interfejsu, zapewniając ogromną funkcjonalność programistom zewnętrznym. Frameworki pozwalają programistom skupić się na rozwiązywaniu problemów biznesowych, a nie na określaniu szczegółów, które już zostały określone, np. na ile czasu między dwoma kolejnymi dotknięciami stanowi podwójne dotknięcie. Korzystanie z tych istniejących ram pomaga również zapewnić spójne zachowanie w różnych aplikacjach.
Frameworki mogą być również dystrybuowane przez osoby trzecie. Niektóre z tych frameworków mogą być edytowane przez innych programistów i nazywane są kodem „open source”. Kod źródłowy to oprogramowanie, którego większość użytkowników nigdy nie widzi. To sprawia, że aplikacja działa tak, jak działa. Oprogramowanie Open Source to oprogramowanie z kodem, który każdy może sprawdzać, modyfikować i ulepszać. Innymi słowy, gdy framework jest dystrybuowany jako open source, programiści mogą zmienić kod źródłowy, aby odpowiadał ich potrzebom. Niektóre frameworki są jednak rozpowszechniane bez kodu źródłowego. Ten typ dystrybucji umożliwia programistom zewnętrznym korzystanie z ich funkcji, ale nie może ich zmieniać. W tym przypadku kod źródłowy jest chroniony i niedostępny.
Czasami frameworki zapewniają funkcjonalność, ale nie zawierają interfejsu użytkownika. Jeśli to konieczne, od niezależnego programisty zależy zapewnienie interfejsu. Na przykład aplikacja może wymagać od bieżącej lokalizacji użytkownika przedstawienia listy pobliskich sklepów detalicznych. Inna aplikacja może wykorzystywać te informacje o lokalizacji do gromadzenia ich i przekazywać informacje o tym, jak zatłoczony jest dany obszar. Frameworki udostępniają tylko informacje o lokalizacji, ale aplikacja określa, w jaki sposób wykorzystać te informacje w sposób cenny dla użytkowników.
Innym razem struktura zapewnia funkcjonalność i interfejs użytkownika. Mapy są tego doskonałym przykładem. Mapy Google i Mapy Apple zapewniają ogromną funkcjonalność, często wymagającą niewielkiej dodatkowej pracy dla programistów zewnętrznych. Deweloper może przydzielić obszar ekranu (lub cały ekran) do mapy, dodać trochę informacji o konfiguracji, takich jak to, czy bieżąca lokalizacja użytkownika powinna być wyświetlana, czy opcjonalnie podać listę pinezek, które mają być wyświetlane. Struktura map obsługuje prawie wszystkie ciężkie operacje, a deweloper nie musi pisać dodatkowego kodu.
Jak już wspomniano, Apple i Google zapewniają ogromne frameworki, które sprawiają, że programiści mogą tworzyć aplikacje mobilne bez wysokich kosztów, które byłyby wymagane do „klepania kodu” każdego elementu. Podobnie wiele znanych aplikacji zorientowanych społecznie, które programiści mogą wykorzystać do ułatwienia połączeń między aplikacjami. Obejmuje to wszystko, od sieci relacji (np. LinkedIn, Tinder), po sieci udostępniania multimediów (np. YouTube, Flickr), sieci blogów lub publikowania (np. Reddit, Medium).
Istnieje również wiele innych firm oferujących mniejsze funkcje, podobne do frameworków, które można osadzić w aplikacji. Analityka użytkowania jest jedną z takich funkcji. Amazon, Google, Mixpanel i inne oferują frameworki, które będą rejestrować aktywność użytkowników w aplikacji i dostarczać te dane na serwer, na którym możesz przeglądać raporty i ulepszać swoją aplikację na podstawie wyników, które widzisz.
Ważne jest, aby pamiętać, że wykorzystanie istniejących danych nie zawsze jest możliwe. Na przykład, wyobraź sobie, że chcesz stworzyć kolejną świetną aplikację do współdzielenia jazdy. Mógłbyś skorzystać z algorytmów planowania trasy Uber lub Lyft. Pozwoliłoby to zaoszczędzić znaczne koszty rozwoju, ale nie jest możliwe, ponieważ firmy te nie oferują tej funkcji we frameworku. Ten kod jest dla nich przewagą konkurencyjną, więc utrzymują go jako prywatny.
Czasami nie jest rozsądnie korzystać z dostępnych danych. Należy upewnić się, że pochodzą one z wiarygodnego źródła, które będzie nadal obsługiwane tak długo, jak Twoja aplikacja istnieje. Kiedy framework jest dostarczany przez firmę lub niezależnego programistę, który traci zainteresowanie produktem, możesz zostać z wyzwaniem zastąpienia go lub usunięcia, gdy nie jest już kompatybilny ze zaktualizowanymi bazowymi platformami Apple i Google. To, co w krótkim okresie wydawało się szybkim i niedrogim rozwiązaniem, może stać się kosztowną propozycją, jeśli zostaniesz zmuszony do zastąpienia go później.
A co, jeśli Twoja firma chce, aby programiści umieścili w swoich aplikacjach funkcje Twojej aplikacji? Jeśli utworzysz aplikację społecznościową, prawdopodobnie zainteresuje Cię jak najłatwiejsze publikowanie treści w aplikacji, bez względu na to, jak się tam dostanie. Możesz stworzyć strukturę ułatwiającą zewnętrznym programistom dodawanie funkcji publikowania swojej platformy do swojej aplikacji. Następnie, gdy inni programiści używają Twojej platformy do publikowania, płacą ci za każdym razem, gdy z niej korzystają. Jak wspomniano powyżej, możesz zapewnić tę funkcjonalność z dowolnym interfejsem użytkownika lub bez niego.
Istnieje wiele możliwości dla aplikacji biznesowych. Na przykład fakturowanie medyczne jest skomplikowane – wszystkie diagnozy i procedury mają powiązane kody numeryczne, które pojawiają się na rachunku medycznym pacjenta. Niektórych procedur nie można obciążać innymi procedurami. Niektóre procedury mogą być rozliczane tylko pod pewnymi warunkami. Jeśli byłeś firmą z doświadczeniem w zakresie rozliczeń medycznych zawartą w systemach oprogramowania, możesz spakować tę wiedzę w ramach, które udostępnisz innym firmom, aby włączyć je do swoich aplikacji. Uruchomienie na rynku medycznym może skupić się na rozwiązaniu unikalnego problemu w branży, ale nadal zapewniać klientom usługi rozliczeniowe, wykorzystując ramy rozliczeniowe. Dzięki temu oszczędza się czas i koszty niezbędne do opracowania własnej ekspertyzy rozliczeniowej.
Jeśli chcesz dodać funkcje do swojej aplikacji, integracja aplikacji może zaoszczędzić czas i pieniądze. Jeśli jesteś w stanie udostępnić framework innym osobom, taka integracja aplikacji może być dla Ciebie szansą na zwiększenie przychodów lub pomóc w poszerzeniu zasięgu Twojej aplikacji lub platformy. Skontaktuj się z nami, jeśli chcesz dowiedzieć się więcej.
Trading jest jednym z najtrudniejszych zawodów na świecie, wymaga silnej woli opanowania, wyczucia i szybkiego dostosowywania się do zmian na rynku. Profesjonalni traderzy na co dzień analizują swoje pozycje, przeglądając dziesiątki wykresów, na których kreślą swoje kreski, aby znaleźć odpowiedź czy to właściwy moment wejścia do gry. Kiedy wszystko jest już zaplanowane, trzeba wystawić zlecenia, co często bywa żmudnym zdaniem, a niekiedy wymaga błyskawicznych reakcji i precyzji. W celu ułatwienia i tak trudnej pracy Tradera przychodzą boty. Mądre wykorzystanie bota, może ułatwić i zoptymalizować pracę.
Jest to fragment wywiadu, który udzieliłem na łamach portalu BitHub.pl. Więcej można poczytać pod tym linkiem.
A czym jest KryptoBot, możesz się przekonać oglądając poniższy film:
Na temat zarządzania projektami IT powstała w zasadzie nieskończona ilość stron, książek, programów, filmów. Terminy takie jak: Scrum, Agile, Kanban są szeroko opisywane, wyjaśnianie i analizowane. Znacznie trudniej znaleźć można artykuły traktujące realne problemy, wykraczające poza idealny świat opracowań książkowych.
Ten wpis powstał z chęci podzielenia się latami doświadczeń w zarządzaniu projektami IT. Określone zostały najważniejsze problemy związane z produkcją oprogramowania.
Najczęstszym problemem jest nadużywanie terminu „gotowe” i jego synonimów takich jak zrobione, done. Zdecydowana większość osób zaangażowanych niewłaściwie i zbyt pochopnie używa określenia „gotowe”. Wbrew pozorom zdefiniowanie, czy projekt, lub jego część są gotowe jest dość trudne. Można użyć porównania z gotowaniem obiadu, gdzie trzeba zrobić zakupy, ugotować obiad, pozmywać i posprzątać po obiedzie. Jak powszechnie wiadomo, dla niektórych obiad, to tylko zrobienie zakupów, dla niektórych to zrobienie zakupów i konsumpcja posiłku, a dla niektórych obiad jest skończony jak jest po nim pozmywane i posprzątane. Ta analogia, pomimo swojej prostoty, jest skalowalna na projekty IT. Dlatego poniżej zaprezentowane są popularne przypadki, w których nie można mówić, że coś jest „gotowe”. Dodatkowo każdy przypadek oferuje jeden output – wyjście projektowe w procesie produkcji oprogramowania, które identyfikuje, że task nie jest „gotowy”. Takich output-ów może być wiele, ale dla uproszczenia opisu zaprezentowany jest ten najważniejszy. Nie oznacza również, że realizacja output-u ustawia status zadania na „gotowe”.
Przykłady poniżej:
Uzyskanie statusu „gotowe” umożliwia zablokowanie wykonanego zadań. Oczywiście, jeżeli istnieje wyraźna potrzeba można wrócić do zadania, ale już w czasie dodatkowym. Potwierdzenie przez klienta wykonania zadania i ustawienia jego statusu na „gotowe” jest jednym z kluczowych aspektów prowadzenia projektu. Bardzo ważne, aby poszczególne sprinty w dużym projekcie uzyskiwały status „gotowe”, tak szybko jak to możliwe. Definicja „done” wydaje się być prosta. Jest to etap, w którym możemy klientowi wystawić fakturę i nie wracać już do tego zadania w tym projekcie.
Częstym problemem opóźniającym realizację projektów IT są uciążliwe drobiazgi wynikające ze złej komunikacji wewnątrzprojektowej.
Komunikacja z klientem to kluczowa rzecz i powinna być prowadzona przez osobę posiadającą łatwość nawiązywania kontaktów.
Bardzo ważne jest poszanowanie każdej ze stron w projekcie i w momencie pojawienia się problemów nie obwinianie nikogo, tylko poszukiwanie rozwiązania. Komunikacja z klientem powinna być prowadzona jasnymi i przejrzystymi komunikatami i klarownymi opisami zagadnień, co nie jest łatwe dla osób technologicznych. Bardzo ważnym elementem realizacji projektu jest wywiązywanie się klienta z zadań.
Nie ma szans na terminowe wykonanie, jeżeli klient sprawnie nie odpowiada na pytania i nie współpracuje. Jest on częścią projektu i musi zdawać sobie z tego sprawę. W wielu przypadkach trudno jest wyegzekwować wywiązywanie się z obowiązków jakie spoczywają na kliencie, ale nawet najlepszy zespół nie skończy należycie i na czas projektu bez obustronnej współpracy.
Ostatnim aspektem, z którym wiążą się opóźnienia projektowe jest całkowity brak zarządzania projektem przez osobę kompetentną w tym zakresie. Skutkuje to ignorancją dziennych spotkań co prowadzi do sytuacji, w której deweloper zaczyna pracować nad „swoją” wersją projektu. Brak wyznaczonych zadań wpisanych w ramy czasowe powoduje, że programiści przeskakują pomiędzy zadaniami. Wtedy na pytanie klienta, co w rzeczywistości zostało wykonane najczęstszą odpowiedzią są stwierdzenia w tylu „w zasadzie gotowe”, lub „prawie gotowe” – czyli krótko mówiąc nie gotowe.
Ignorowanie regularnych spotkań z klientem spowoduje, że wizja projektu prawie zawsze będzie rozbieżna pomiędzy stronami. Trzeba pamiętać, że wielu właścicieli firm IT popełniło błąd niezatrudnienia doświadczonego menadżera projektów. PM nie tworzy kodu i nie daje namacalnego wkładu w rozwój oprogramowania, ale jego brak w przeważającej większości przypadków powoduje zwiększeniem kosztów wykonania projektu i naraża na szwank reputację firmy. Stąd bardziej opłaca się zainwestować w dobrego PM niż podjąć ryzyko wykonania projektu IT bez niego
