Preferencje help
Widoczny [Schowaj] Abstrakt
Liczba wyników

Znaleziono wyników: 13

Liczba wyników na stronie
first rewind previous Strona / 1 next fast forward last
Wyniki wyszukiwania
help Sortuj według:

help Ogranicz wyniki do:
first rewind previous Strona / 1 next fast forward last
PL
Artykuł dotyczy analizy możliwości wykorzystania aplikacji do tworzenia diagramów przepływu danych przy wykorzystaniu QSEE Superlite oraz aplikacji stworzonej we frameworku Flutter. Celem artykułu jest dokonanie analizy porównawczej czasu potrzebnego do stworzenia diagramu przepływu danych, a także oceny użytkowników pod kątem przejrzystości interfejsu oraz swobody działania w każdej z aplikacji. Postawiono dwie hipotezy badawcze: „DFD Maker pozwala na szybsze tworzenie diagramów przepływu danych w porównaniu do QSEE Superlite” oraz „DFD Maker ma przyjaźniejszy interfejs dla użytkownika w porównaniu do QSEE Superlite co pozwala na łatwiejsze tworzenie diagramów przepływu danych”, które po analizie wyników, przeprowadzonych badań, zostały udowodnione.
EN
This article analyzes the possibility of using application to create data flow diagrams, by using QSEE Superlite and the application created in Flutter framework. The purpose of the article is to make comparative analysis of the time needed to create a data flow diagram, as well as to evaluate users in terms of interface transparency and freedom of action in each application. Two research hypotheses have been formulated: “DFD Maker enables faster creation of data flow diagrams compared to QSEE Superlite” and “DFD Maker has a more user-friendly interface compared to QSEE Superlite, allowing for easier creation of data flow diagrams”, which were confirmed after analyzing the results of the conducted study.
EN
This paper evaluates the feasibility of deploying locally-run Large Language Models (LLMs) for retrieval-augmented question answering (RAG-QA) over internal knowledge bases in small and medium enterprises (SMEs), with a focus on Polish-language datasets. The study benchmarks eight popular open-source and source-available LLMs, including Google’s Gemma-9B and Speakleash’s Bielik-11B, assessing their performance across closed, open, and detailed question types, with metrics for language quality, factual accuracy, response stability, and processing efficiency. The results highlight that desktop-class LLMs, though limited in factual accuracy (with top scores of 45% and 43% for Gemma and Bielik, respectively), hold promise for early-stage enterprise implementations. Key findings include Bielik's superior performance on open-ended and detailed questions and Gemma's efficiency and reliability in closed-type queries. Distribution analyses revealed variability in model outputs, with Bielik and Gemma showing the most stable response distributions. This research underscores the potential of offline-capable LLMs as cost-effective tools for secure knowledge management in Polish SMEs.
PL
Artykuł dotyczy porównania wydajności interfejsu graficznego frameworka Flutter w środowisku natywnym na platformie Windows oraz na środowisku webowym, na tym samym urządzeniu. Celem artykułu jest dokonanie analizy porównawczej czasów budowy i przebudowy ekranów na obydwu środowiskach. Na potrzeby pracy została wykonana aplikacja testowa w której skład wchodzą ekrany o różnym typie złożoności. Postawione tezy: “Platforma Flutter jest mniej wydajna w środowisku webowym w porównaniu do środowiska natywnego pod względem czasu ładowania widoków.” oraz “Platforma Flutter jest mniej wydajna w środowisku webowym w porównaniu do środowiska natywnego pod względem czasu przebudowywania widoków” zostały udowodnione
EN
This article compares the performance of the Flutter framework's graphical user interface (GUI) in a Windows platform native environment and in a web environment on the same device. The purpose of the article is to make a comparative analysis of screen building and rebuilding times in both environments. For the purpose of the paper, a test application has been created in which screens of different types of complexity are included. The stated theses: "The Flutter platform is less efficient in the web environment compared to the native environment in terms of view loading times." and "The Flutter platform is less efficient in a web environment compared to a native environment in terms of view rebuilding time" have been proven.
EN
The purpose of this paper is to compare the performance of microservices based on reactive and imperative approaches. For this purpose, two microservice applications written in Java using the Spring programming framework were developed. The Spring Web and Spring Webflux modules were used for the conventional and reactive versions, respectively. During the tests, functionalities related to operations of retrieving and inserting records into the database, data processing, and file transfer were invoked. The Gatling tool was used to conduct the tests. The tests showed that reactive microservices can be more efficient in particular when there are delays in communication with services or the database. Otherwise, it depends on the complexity of the operations being performed. Microservices based on the reactive paradigm also use less RAM compared to conventional counterparts.
PL
Celem pracy było porównanie wydajności mikroserwisów opartych o podejście reaktywne i imperatywne. Aby wykonać zadanie, stworzono dwie aplikacje mikroserwisowe napisane w języku Java z użyciem szkieletu programowania Spring. Wykorzystane zostały moduły Spring Web oraz Spring Webflux odpowiednio dla wersji konwencjonalnej i reaktywnej. W trakcie badań wywoływane były funkcjonalności związane z operacjami pobierania i wstawiania rekordów do bazy danych, przetwarzania danych, przesyłania plików. Do przeprowadzenia testów wykorzystano narzędzie Gatling. Badania wykazały, że mikroserwisy reaktywne mogą być wydajniejsze w szczególności w przypadku występowania opóźnień wkomunikacji z serwisami lub bazą danych. W innym razie jest to zależne od złożoności wykonywanych operacji. Mikroserwisy oparte o paradygmat reaktywny, wykorzystują również mniej pamięci RAM w porównaniu z konwencjonalnymi odpowiednikami.
5
Content available Usage of IoT edge approach for road quality analysis
EN
In the paper, the authors present the analysis of implementation of IoT system for road quality analysis. The proposed system was prepared for edge processing, on device. It allows to reduce the amount of data sent to cloud computing aggregation subsystem, sending only 2.5% of the original data. Several algorithms for road quality analysis were implemented on a real device and tested under real conditions. The system was compared with the state-of-the-art offline processing approach and showed the same accuracy on a set of known road artefacts, while detecting 92% of the artefacts recognized by the original cloud computing processing system.
EN
The article addresses the challenge of reconstructing 2D broken pictorial objects by automating the search for matching elements, which is particularly relevant in fields like archaeology and forensic science. The authors propose a method to match such elements and streamline the search process by detecting and filtering out low quality matches. The study delves into optimizing the search process in terms of duration and assembly quality. It examines factors like comparison window length, Levenshtein measure margin, and number of variants to check, using theoretical calculations and experiments on synthetic elements. The experimental results demonstrate enhanced method effectiveness, yielding more useful solutions and significantly reducing the complexity of element comparisons by up to 100 times in extreme cases.
EN
In the paper, the authors are presenting the outcome of web scraping software allowing for the automated classification of source code. The software system was prepared for a discussion forum for software developers to find fragments of source code that were published without marking them as code snippets. The analyzer software is using a Machine Learning binary classification model for differentiating between a programming language source code and highly technical text about software. The analyzer model was prepared using the AutoML subsystem without human intervention and fine-tuning and its accuracy in a described problem exceeds 95%. The analyzer based on the automatically generated model has been deployed and after the first year of continuous operation, its False Positive Rate is less than 3%. The similar process may be introduced in document management in software development process, where automatic tagging and search for code or pseudo-code may be useful for archiving purposes.
EN
The paper presents an approach to solving the problem of assembling broken, flat elements using a letter notation of the elements’ contours and checking their matching using linguistic methods. Previous studies with the use of exhaustive search have shown effectiveness in finding possible connections, but they are burdened with a large number of calculations and the time needed to carry them out. In order to accelerate the process of searching for solutions, the possibility of using a fail-fast method of fuzzy assessment of potential combinations of elements was checked, as well as the method of cutting off potential, but not effective connections. The numerical experiment carried out showed a significant reduction in the number of trials and total computation time while maintaining the quality of the potential solutions found.
9
Content available Porównanie wydajności protokołu WebSocket i HTTP
EN
The purpose of the author of this article is to compare the performance of the WebSocket and HTTP protocols. For this purpose, LAN equipment and a self-made testing application were used. It was used to measure the time of sending and downloading/receiving 100-character texts in a specified number of copies, considering the speed of laptops and web browsers. The conducted research shows that when transmitting more than 100 copies of data using the WebSocket protocol (compared to HTTP), performance can be increased by several hundred percent. In addition, it has been proven that adding excess overhead to HTTP requests can slow it down considerably. In contrast, TLS encryption has little effect on the speed of both protocols. It was concluded that the WebSocket protocol is good for sending hundreds or thousands of small serving of data per second, because for a smaller number of them, a simple HTTP polling is absolutely enough.
PL
Celem autora tego artykułu jest porównanie wydajności protokołu WebSocket i HTTP. W tym celu wykorzystano sprzęt pracujący w sieci LAN oraz samodzielnie wykonaną aplikację testującą. Za jej pomocą zmierzono czas wysyłania oraz pobierania/odbierania 100-znakowych tekstów w określonej liczbie kopii z uwzględnieniem szybkości laptopów i przeglądarek WWW. Z przeprowadzonych badań wynika, że przy transmisji powyżej 100 kopii danych za pomocą protokołu WebSocket (w porównaniu do HTTP) można uzyskać wzrost wydajności o kilkaset procent. Ponadto udowodniono, że dodawanie nadmiarowych narzutów do żądań HTTP może go bardzo spowalniać. Natomiast szyfrowanie TLS ma znikomy wpływ na szybkość obu protokołów. Wywnioskowano, że protokół WebSocket dobrze sprawdzi się w przesyłaniu setek lub tysięcy małych porcji danych na sekundę, gdyż w przypadku mniejszej ich liczby w zupełności wystarczy zwykłe odpytywanie HTTP.
PL
Ten artykuł jest poświęcony porównaniu szybkości kompilowania kodów preprocesorów SCSS oraz LESS. Każdy preprocesor ma swoją składnię, która w ciągu dalszym tworzenia strony webowej jest transpilowana do składni języka arkuszy stylów CSS. Technologie te służą temu samemu celowi – uproszczeniu i przyśpieszeniu pisania widoków stron, ale bazują się na różnych językach programowania – języku Ruby (SCSS) oraz JavaScript (LESS). W ramach przepro-wadzonych badań dokonano pomiarów czasów kompilacji kodów w formacie SCSS i LESS o rozmiarach 10, 50, 100 i 200 kB, otrzymane wyniki jednoznacznie pokazały, że szybszym narzędziem do przetwarzania kodu na składnię CSS okazał się LESS. W analizach pod uwagę również wzięto wielkość kodu wynikowego CSS.
EN
This article compares the compilation speed of the SCSS and LESS preprocessor codes. Each preprocessor has its own syntax, which is transpiled into the CSS stylesheet language in the further development of the web page. These technol-ogies serve the same purpose - to simplify and speed up the writing of page views, but are based on different program-ming languages - Ruby (SCSS) and JavaScript (LESS). As part of the research, the compilation times of the codes in the SCSS and LESS format with sizes of 10, 50, 100 and 200 kB were measured, the obtained results clearly showed that LESS turned out to be a faster tool for processing the code into CSS syntax. The size of the CSS result code was also taken into account in the analyzes.
PL
W ramach pracy nad artykułem stworzone zostały dwie gry 2D - jedna przy użyciu środowiska Unity oraz druga przy użyciu LibGDX. Szczególną uwagę w pracy poświęcono porównaniu wydajności obu gier. W tym celu przeprowadzo-no badania, które miały na celu określenie, która z gier ma lepszy wpływ na zużycie zasobów procesora oraz pamięci RAM. Poświęcono również uwagę wsparciu społeczności dla obu narzędzi oraz komfortowi programisty podczas pracy w obu wspomnianych narzędziach. Wyniki badań wydajności sugerują, że LibGDX może być lepszym wyborem do tworzenia niewielkich projektów, których priorytetem jest wydajność. Na korzyść Unity przemawia jednak wsparcie społeczności oraz komfort korzystania z tego środowiska i brak konieczności korzystania z programów zewnętrznych.
EN
As part of the work on the article, two 2D games were created – one based on the Unity environment and the other based on LibGDX. Main focus in the work was to compare the performance of both games. For this purpose, research was carried out to determine which game has a better impact on the usage of CPU and RAM resources. Attention was also paid to community support for both tools and the programmer’s comfort during the work in both of these tools. The results of the performance studies suggest that LibGDX may be a better choice for creating small projects where performance is a priority. However, the support of the community and the comfort of working with the environment and the lack of need to use external programs speak in favor of Unity.
EN
The paper describes the process of analyzing the data of the Polish community on the Twitch.tv streaming platform. A description of the platforms and tools used to research the data was presented. The research was conducted on the basis of three issues. Data on the number of live broadcasts and the number of recipients were analyzed. Separate charts have been generated for each of them. The code used to create the charts was written in the R language. Conclusions were drawn on the basis of the generated charts.
PL
W pracy został opisany proces analizowania danych polskiej społeczności na platformie streamingowej Twitch.tv. Przedstawiony został opis platform oraz narzędzi wykorzystanych do badania danych. Badania zostały przeprowadzone w oparciu o trzy zagadnienia. Analizie poddane zostały dane dotyczące ilości nadawanych transmisji na żywo oraz liczby odbiorców. Do każdego z nich zostały oddzielne wygenerowane wykresy. Kod służący do stworzenia wykresów został napisany w języku R. Na podstawie wygenerowanych wykresów wyciągnięte zostały wnioski.
13
Content available Crowdsourced Driving Comfort Monitoring
EN
In this paper, the authors are showing a calculation of the road quality index called Simple Road Quality Index (SRQI) using the weight provided by the amateur drivers to best possibly rate their comfort on driving on that road. The index is calculated from acceleration data acquired by the smartphone application and is aggregated in a crowdsourcing system for the classification of road quality using the fuzzy membership function. The paper shows that the proposed index correctly shows road quality changes over time and may be used as a way to mark roads to be avoided or needs to be repaired. The numerical experiment was based on the same street in Lublin, Poland, in 2015-2021 and is correctly showing that the quality of analyzed roads deteriorated over time, especially in the winter season.
first rewind previous Strona / 1 next fast forward last
JavaScript jest wyłączony w Twojej przeglądarce internetowej. Włącz go, a następnie odśwież stronę, aby móc w pełni z niej korzystać.