Noutați

What You Should Know About This Epic Telegram Sticker Browser

Skia4Delphi is one of the most useful open-source 2D graphics libraries and windows app development tools that can supercharge your FireMonkey and VCL apps’ user interface. One of the notable advantages of using this library is that it gives you the ability to combine or merge different animations with transparency that certainly adds that “wow factor” to your apps. In this video, we will get to know more about the quick and easy process of adding your favorite Lottie Animations and Telegram Stickers using the TelegramStickerBrowser project that is written in Delphi with the Skia4Delphi library. How to Download Stickers from Lottie and Telegram Lottie is a JSON Based Animation format that can easily add high-quality animation to any native app. TSkLottieAnimation is one of Skia4Delphi’s main components that allows users to easily overlay animations on top of each other. We can also recall Ian Barker managed to simulate a Star Trek-inspired data dashboard using these components. Lottie is an iOS, Android, and React Native library that renders After Effects animations in real time, allowing apps to use animations as easily as they use static images. They are also notably small files that work on any device and can scale up or down without pixelation. Aside from Lottie Animations, you can also download Stickers from Telegram, a popular messaging platform. To do so, simply browse the stickers you want using the Sticker Downloader Bot in Telegram. Copy the sticker to the clipboard and paste it into the chat box. This will provide you with a link to download which you can easily load to Delphi via the TelegramStickerBrowser component. How to Use TelegramStickerBrowser TelegramStickerBrowser, as the term clearly suggests, is a desktop browser for Telegram stickers (TGS) and Lottie (JSON) animation files. This uses the Skia4Delphi library that provides you access to a great number of free and high-quality animations. The TelegramStickerBrowser includes a small selection of colorful and HD stickers from LottieFiles but you can also download additional stickers from Telegram via the StickerDownload bot. Mckeeth will also demonstrate how to export these stickers from After Effects. If you want to learn more about this fascinating project that can supercharge your app’s interface, feel free to watch the video below.

Read More

Take our DevOps quiz!

We’re hoping to stump you…and we stumped ourselves on some of these questions for sure. There are just 10 questions, so dive in, and you’ll see your score at the end. “What’s the most obscure programming language? Will AIOps be in your future? Take our DevOps quiz and find out.” – GitLab Click to tweet Sign up for GitLab’s twice-monthly newsletter

Read More

Best Open Source Low Code Platform: Expectations vs. Reality

As a fast and easy alternative to traditional software development, an open source low code platform is fast becoming the hot topic. By 2026, the open source software and services market is expected to reach a whopping $50B. This incredible expansion and growth is thanks largely due to the prediction that 75% of large enterprises are expected to use at least 4 low-code development tools.   Let’s unpack that assertion a little here along with some background information on what open source is and how low code platforms factor into these estimates of accelerated uptake into low code or no code development solutions. What is anopen source low code platform? Since the buzz of low code platforms is everywhere, chances are you are familiar with the word. What exactly is it? Here is the definition  “A low code platform is used to imply visual interfaces with basic logic like drag and drop with little to no coding in a platform” Why is it called an open source low platform? Because the source code is free and easily available to download, deploy and edit by the end user where it deems fit. In simple words, an end user can view, copy, learn, alter or share the code. They are used for scalability in building applications and processes. The platform may vary by requirements so if you want to get started here is the beginner’s guide you must check out! What are the pros of open source low code platform? 1. Flexibility  Flexibility is a crucial quality of open source software that supports this approach to, software deployment. The end-user can have ultimate modification possibilities based on developer resources and requirements without any hassle or fear of the company’s terms and conditions being broken. 2. Reliability  For open-source software, the user relies on the corporation to update, patch, and enhance the codebase, as well as the community. Updates and patches can be maintained and supported by the community. 3. Control and fast transformation Organizations are better positioned to adapt and respond to rapidly changing business situations because to these low-code features so that for their own deployment, the end-user can alter and control the application’s basic code. Companies with the resources to do so can use this to create a product that is truly suited to given requirements. 4. Higher Productivity What used to take months now takes days, if not minutes now, thanks to low-code development. Which allows more apps to be produced in as little time as possible. Time is no longer an impediment to true innovation all because of low-code development. 5. Open Community  The code can be peer-reviewed and maintained by participants in an open source community having passionate programmers and coders. This is indicative of the open source development community’s collaborative and helpful nature such as (Wikipedia, GitHub, etc). 6. Low cost With the ability to build more apps in less time, decreases in cost have been observed. Using low-code tools, the average organization avoids hiring two IT developers. Over the course of three years, the applications designed generated around $4.4 million in enhanced corporate value. – (Forrester) Expectation vs Reality – What is the Gap? Low-code means not having any code As the name suggests, is kind of true. It requires at least a little coding depending on some […]

Read More

Extend TMS WEB Core with JS Libraries with Andrew: Tabulator Part 2: Getting Data Into Tabulator

Last time out, we started our adventure into Tabulator, a JavaScript library that provides a grid-style control that you can use in your TMS WEB Core projects. This time out, we’re going to focus on just one aspect – getting data into Tabulator.  The material in this post may also be of interest generally, no matter the grid control you’re using, or even if you’re just looking to get data into your TMS WEB Core application generally.  We’re going to dip our toe into SPARQL, used to query the data behind Wikipedia.  We’ll also show how to quickly set up an XData server as a proxy, both for SPARQL and other remote data sources.  This should be fun! Motivation. Tabulator, and virtually every other JavaScript-based grid control, is expecting to get data in JSON format, where the various components involved along the way have differing levels of rigidity when it comes to the JSON format itself, unfortunately, as will see. Sometimes other formats are supported, like XML or CSV, but JSON is almost always the primary method. This isn’t much of a surprise, of course, as JavaScript and JSON are very closely related to one another. Many interesting remote sources of data can be accessed via a REST API, and will often also, if you ask politely, return data in a JSON format.  All good.  However, formulating requests acceptable to the remote server, and being able to actually get the bits of data out of the JSON that you get back, can sometimes be adventures all their own. And at the same time, there may be issues in terms of how much data you can request from a remote API or how fast it can serve up the data you are interested in.  You might also be required to use an API key to make requests that you absolutely do not want to include in your TMS WEB Core application (or any JavaScript client application). And if you’re accessing multiple remote data sources, you might be multiplying the potential headaches to come. So in this post, we’re going to contact multiple remote data sources. We’re going to use a private API key. And we’re going to address performance aspects of the data we’re using.  Along the way, we’ll also be looking to explore a broader array of data types (images, for example).  And once we finally get hold of some data, we’ll add it to a Tabulator table.  We’ll also see if we can add a few nice finishing touches along the way, to help balance some of the Tabulator content in other upcoming posts. The example we’re going to develop here is a simple one, at least to visualize.  We want to use a date picker to select a birthday.  With that birthday, we want to see a list of all of the actors (movies and TV shows) that share that birthday.  And if we select an actor, we want to see all the movies and TV shows where they had a role.  Sounds easy enough right?  Well, the challenges here are not with TMS WEB Core or with Tabulator, but rather with the complexities of getting data from remote data sources.  But these are all solvable problems.  Just maybe a little more tenacity is required. Be warned, odd […]

Read More

Behind the scenes of Subway Surfers: A Q&A with SYBO

What have been the biggest challenges with scaling up so fast? Mathias: For a smaller studio to be supporting a game with 100 million players is an extreme task. It’s incomprehensible that there was a young team operating such a massive game. We, along with Unity, grew as the industry grew, so everything, including the parameters, were changing quickly.  Our goal from the beginning was to give gamers the best possible feeling when playing Subway Surfers, and we keep this in mind with every step and decision we make. We took over publishing for the mobile platforms in mid-2020. For the last 18 months, we’ve been speed learning how to self-publish.  We’ve improved the game, but there’s always the potential to continue to grow and optimize. When we took over self-publishing, initially we were deactivated on the ad platform, because although we only started with 10% of our player base, it amounted to 10 million players, and they thought we were hackers.   How about the technical challenges? Murari Vasudevan: On the technical side, for iOS and Android, the scale of the number of devices is enormous. For Android, there are more than 20,000 unique devices. When we took over publishing, we needed to ensure that the game ran smoothly on all devices that we targeted.  We had issues with performance exceptions and crashes, and with the application not responding. We dealt with the scale of each of these issues happening live, as well as the need to diagnose it in real-time. In order to not put off our player base, we needed to look at the Unity Profiler, optimize, and work with the loading time. We needed to ensure that the loading time matched or improved upon the original.  To ensure good gameplay on even the least-powerful smartphones, we devised a number of techniques, including batching level geometry to reduce draw calls, rotating coins using C# scripts running on the CPU rather than shaders running on the GPU to further minimize draw calls, minimizing UI redraws and ensuring optimal timing in level generation, and not generating more content than a user can see. The Unity Profiler and Frame Debugger make it much simpler to monitor exactly how all these techniques are working. We also use Unity’s different quality settings to optimize fps and refresh rates on low-end devices. We spent a lot of time tweaking our bootstrapping funnel and optimizing our code to ensure that we were really efficient in our process. We had to have a lot of analytics in place to see what players were doing, how they were going through the various stages, and where they were dropping off. This was the flow that came with taking over so many devices and players, and it was an ongoing challenge we had to confront right from the start.

Read More

Detecting performance bottlenecks with Unity Frame Timing Manager

The Frame Timing Manager is a feature that provides frame-level time measurements like total frame CPU and GPU times. Compared to the general-purpose Unity Profiler and Profiler API, the Frame Timing Manager is designed for a very specific task, and therefore comes with a much lower performance overhead. The amount of information collected is carefully limited as it highlights only the most important frame stats. One main reason for leveraging the Frame Timing Manager is to investigate performance bottlenecks in deeper detail. This allows you to determine what curbs your application performance: Is it bound by the main thread or render thread on CPU, or is it GPU-bound? Based on your analysis, you can take further action to improve performance. The dynamic resolution feature supports fixing detected bottlenecks on the GPU side. You can then increase or reduce rendering resolution to dynamically control the amount of work on the GPU. During development, you can even visualize timing in an application HUD, which allows you to have a real-time, high-level mini Profiler built right in your application. This way, it’s always readily available to use. Lastly, you can use the Frame Timing Manager for release mode performance reporting. Based on collected information, you can send statistics to your servers regarding your application’s performance on different platforms for better overall decision-making.

Read More

The Best Native App Builder Whitepaper You’ll Never Forget

There is a fascinating conversation between Neo and the Oracle in The Matrix Reloaded movie. Neo asks the oracle that if she already knows, how can he make a choice? She cleverly replies because you have already made your choice. You only came to me to try to understand why? Thus, it is strange that we often pick things emotionally and then logically persuade ourselves that we have chosen the best option. As a result, we come to comparison not to find the best option but only to convince, rationalize, or understand our own decision. We are prone to make the same mistake while choosing the best native app builder for development. It is easy to choose between good and evil but choosing between good and better is always challenging. Choosing the best one is always a difficult task because we must consider many things. For example, say there are three Native App Builders on the shelf. A is free but least productive, B is an excellent value for money, and C is overhyped. If we choose anything other than B, that will be poor and against our interests. Also, we will be misusing our financial vote, depriving a great company of developing more excellent products for us. Thus, we need extensive research to finalize a development tool. Fortunately, a new whitepaper helps us by evaluating three Windows application development frameworks, and you can download it for free now. What have we not learned from the DOTCOM bubble? Due to several reasons, it is easy for companies with deep pockets to exaggerate things in the software industry. Firstly, because it is software, one cannot SEE or correctly measure the end product. Secondly, its long-term consequences might become evident only after several years, and thirdly, many decision-makers do not have a total grasp of tech. Thus, they turn towards heuristics and guesstimates. This situation makes a perfect ground for snake oil marketers to join the party and profit from other people’s losses. It happened on an immense scale during the DOTCOM bubble, but it is constantly happening on different levels in the software industry. Carefully reading this Whitepaper might save you from investing in a poor tool. What might they be hiding from you? Why is a software production system designed in the way it is? There are technical and historical reasons, but there might also be some control reasons. Many tools are designed with such a mindset that the more users invest in the system, the stronger the owner company becomes. Thus, individual users lose power and control in the long run, and the parent company gets stronger and stronger, just like social media. Fortunately, it is easy to spot such practices. The more proprietary files you have to ship with the end product, the closed the system is, and the developer will have less control over the product in the long run. What are your criteria for choosing the best native app builder? Many people search for the best free app builder, while others look for the best app builder without coding. Some prefer the fame of the tool, and some like its history. These choices might not be comprehensive. We need specific criteria covering all aspects of the software development life cycle. Our Whitepaper includes all necessary points […]

Read More

GRUI By Sencha vs. React Grid: Which Is Better?

  GRUI by Sencha is a high-performance grid solution for React apps. It can efficiently deal with a massive amount of data. Also, it is very easy to integrate with React. On the other hand, React Grid layout is a powerful library for the front-end framework. It allows you to create grids with absolute control over the layout. Both GRUI by Sencha and React Grid layout offers powerful capabilities. However, which is the better option? In this article, you will find all the details. What Is GRUI By Sencha? Sencha GRUI is a modern enterprise-grade grid solution for React applications that comes with 100+ data grid features. Sencha GRUI can efficiently handle millions of records, and it can load huge amounts of data with incredible speed. Also, It supports large feature sets, including filtering, grouping, and infinite scrolling. Besides, Sencha GRUI allows you to export data in different formats, like CSV, XLS, PDF, etc. On top of that, it is very easy to use. Overall, it has everything that a high-performance, robust grid should have. Why Should You Use GRUI By Sencha? Capable of efficiently handling millions of records Offers large feature sets, including filtering, grouping, infinite scrolling, etc. Provides full customization control Supports data export to different formats, including CSV, TSV, HTML, PDF, and XLS Provides easy UI component integration to the grid Read: Enterprise Ready React Data Grid | GRUI by Sencha What Is React Grid Layout? React Grid layout is a draggable grid layout. It is a container component that allows you to rearrange and resize content panels. React grid layout is responsive. Therefore, you can use it on a variety of devices, including desktops, laptops, and smartphones. Also, React grid layout provides you with absolute control over the layout. As a result, you can easily customize everything. You can change the column and row widths. Also, you can customize how cells are positioned within the grid. Why Should You Use React Grid layout? Compatible with server-rendered apps Allows you to serialize and restore the layout Supports draggable, resizable, and static widgets Allows you to add or remove widgets without rebuilding the grid Supports responsive breakpoints Read: Why You’re Failing At React Grid View GRUI By Sencha vs. React Grid: Which Is The Better Solution? GRUI by Sencha offers a significantly better solution. Unlike React Grid, it can efficiently handle millions of records. Also, GRUI by Sencha has a smaller footprint and payload than other grid solutions. It ensures that mission-critical apps deliver optimal performance. Does GRUI Offer Faster Data Processing Performance Than React Grid? Slow data processing speed can affect the user experience. You don’t want to see your application users frustrated with sluggish performance. In this case, GRUI comes into play. With client and server-side buffered stores, it can load and manipulate large data sets within milliseconds. It is significantly faster and more efficient than other solutions, including React Grid. Does GRUI Deliver Massive Performance Enhancement With Virtual Columns? GRUI offers virtual columns. It lets you render only the columns that are in the current viewport. It provides several advantages. First, you will get a smoother scrolling experience. Second, it can significantly enhance performance for applications that need large numbers of columns. Let’s take a look at this example: As you can see, it’s a […]

Read More

How to A/B test game difficulty with UGS Use Cases

Perfecting your game’s design can be difficult when you can’t see how your players interact with it. By doing A/B testing, you can make design decisions based on how your players really play the game. The Unity Gaming Services (UGS) Use Cases are a collection of samples that implement typical backend game use cases and game design elements, show how to resolve specific development tasks, and highlight the efficiency you can achieve in your game backend by integrating different UGS packages in your project. One of these samples is about A/B Testing.This lets you segment players into multiple test groups in order to determine which version of a specific game element is the most engaging or intuitive to your players. The example we show is testing the amount of XP required for leveling up. This particular example is suited for something like alpha playtesting of a single-player game. But this is just one example, and there are many potential uses for A/B testing with UGS, even in published or multiplayer games.

Read More

GitLab 15: The retrospective

No cloud native, no containers, and no remote work: Those were just a few of the things missing from the technology landscape in 2011 when we launched GitLab 1.0. It’s been a journey, for sure. Here’s a look back at how far we’ve traveled to get to GitLab 15. It started with source code management In the beginning of GitLab there was source code management (SCM)… and that was it. Continuous integration (CI) became part of GitLab because our co-founder Dmitriy Zaporozhets got tired of having to keep the CI servers running separately, so we decided to bring continuous integration into the mix. Even then we knew it didn’t make sense for companies to “DIY” critical parts of their process. That being said, it did feel counterintuitive to bring SCM and CI together, but we tried it anyway. Continuous delivery (CD) eventually evolved out of the CI/SCM integration, but it is crazy to think that when we started GitLab, CI/CD was not really a consideration. DIY DevOps really did exist What people were talking about, though, was DevOps, and specifically DIY DevOps because back then it was completely normal for teams to assemble a bunch of tools and call it done. When we would talk about the importance of fewer tools and more integration, people would turn up their noses. We heard a lot of “different tools for different things” and “many have sharp tools.” Today we know that a DevOps platform increases development speed and release cadences. But back then, gluing together tools was seen as normal. What’s old is new again Back in the day there were lots of tools and also very different programming languages than we reach for today. In the 2014 era, developers often wrote code in Ruby or JavaScript, and kept things layers away from the microprocessor. Over the years, that’s changed drastically. Rust and Go – as just two examples – have brought us back to the processor and reflect today’s modern programming styles. It’s another sign of how drastically things have shifted over time. It wasn’t cloud-y The cloud was in its infancy when GitLab started and at the time we all thought it was probably a great solution for startups or small businesses, but perhaps not something that would ever be in widespread use. Fast-forward to today where most companies run their infrastructures in the cloud. Now it’s widely accepted a cloud native architecture helps teams deliver better software faster and cloud skepticism has drifted away. Security was siloed Security teams, and tools, were completely separate entities when GitLab began and that, of course, made doing something inherently difficult even more so. Devs were asked to fix bugs without any context, process, or knowledge of deployment status, and naturally weren’t very excited about it all. Realizing this, we began slowly adding scans to our CI/CD steps so that security was part of the pipeline and not separate from it. The goal is to let developers and teams deal with security in an incremental way, rather than a large to-do list at the end of the process. And that progress is ongoing. Code review wasn’t integrated Eleven years ago, code review wasn’t that different from security, i.e., it was something done in a distant time and place and without context. Today, merge […]

Read More