Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Development

    9 articles in this category

      Kotlin Vs. Java: Which is Best for Developing Android Apps?

      For more than two decades, Java was one of the more sought-after programming languages used on a variety of devices. Since the beginning, mobile apps developers have relied on Java to create hundreds of applications. In May 2019, Google announced that Kotlin was the preferred programming language for the Google Play Store for Android applications.
      To develop a successful mobile app, it is crucial to choose the best among Kotlin vs Java languages. Let’s learn what these languages are, their pros and cons, and which one will fit your app project. Let’s look at. Kotlin Programming Language
      Kotlin Programming Language
      Kotlin is mostly the integrated environment used for developing apps. It is also able to create statically JavaScript as well as Java Virtual Machine language (JVM).
      Kotlin is a blend of functional and functional programming. It is more simple, less messy and more efficient to build than Java. Kotlin can convert the code into binary code and run it under JVM. Therefore, it’s suitable for almost every platform & device.
      Java Programming Language
      Java programming language can be described as an object-oriented language. The language is easy to learn, strong, robust, and durable. Java is ideal for Android apps, web applications, server applications, embedded systems, large data and more. Open source is a mix of many elements. Java is the basis of a lot of Android apps and also significant portions of Android.
      Kotlin Vs. Java: What We Need to Know
      Kotlin Vs. Java can’t be used simultaneously for any mobile application development, so it is important to discover which is the most suitable. We’re now going to take a look at the pros and cons of both languages, as well as what makes each one better for certain types of Android applications.
      Data Classes: Kotlin Vs Java
      Java-based Android application development requires you to create variables or fields that can be used to store information. Additionally, you must create constructor, getter and setter methods, as well as toString() and the equals() and hashCode().
      Kotlin automatizes these tasks. You only need to include the word “data” in the definition of the class. The compiler is able to automatically create fields and variables like the setter, getter, constructor, among others.
      Volume & Coding: Kotlin Vs Java
      Kotlin code load is less than Java’s similar programs. Kotlin reduces the chance of errors in code and eases the work of Android app developers. Because of its ease of use, Kotlin is preferred over Java for massive mobile and web application development projects. Kotlin code is easier than Java.
      It doesn’t require constructors to create objects, classes that hold information and get value from declared fields or classes that store the data. Kotlin code is compiled in less than the time required for writing Java code. This accelerates development and deployment.
      Null Safety: Kotlin Vs Java
      Java has many drawbacks, one of which is Null Pointer Exception. The occurrence of a Null Pointer Exception is only triggered when the user is explicit in throwing it. Inconsistencies in data can occur due to Java code problems with initialization, as well as other issues. Kotlin is unable to run when a Null Pointer Exception is generated.
      For the best Kotlin Vs. Java choice and usage, look to hire Android app developers with professional expertise and excellent knowledge.
      Wildcards: Kotlin Vs Java
      Kotlin is not able to use wildcard types. Declaration variance & the type projections are Kotlin’s wildcard choices. Java allows wildcards. Wildcard codes are typically an unidentified kind. It governs the type security of Java-based codes within a software.
      Operator Overloading: Kotlin Vs Java
      You can make use of a range of mathematical operators within Kotlin such as subtraction, addition & division. It is possible to compare objects and conduct quality checks with symbols. The Java programming language relies on particular Java data types with mathematical operators. The Kotlin Vs. Java debate is won by Kotlin in terms of Operator Overloading.
      Performance: Kotlin Vs Java
      JVM runs ByteCode which is written using Java as well as Kotlin. It is however hard to assess their memory consumption. It’s difficult to evaluate and monitor their performance. Kotlin has more features than Java which makes it more practical.
      Multithreading applications are made simpler with Kotlin Coroutines tool. Because of its plethora of features, it compiles & runs a bit slower than Java. Java is however much less complicated than Kotlin which means that it is faster to compile.
      For top assistance, you must seek assistance from a Best Android app development company and hire Android app developers with great expertise.
      Stability: Kotlin Vs Java
      It’s the stability that lets us detect distinctions. Let’s begin with Java. Java is one of the languages with an extensive history. Java Version 8 & Java Version 11 both provide extensive support. If anything goes wrong, the Java versions can be upgraded via patches.
      Despite Kotlin’s long history, it is still a relatively young language. There is no official version yet. Java and Kotlin can be considered to be stable languages. If you are looking for stability, Java is the best option.
      Final Words
      We’ve got the complete list to offer on our analysis of the Kotlin vs. Java Debate. Hopefully, you will be satisfied with our analysis and choose the best option based on your preferences. Be it Java or be it Kotlin, everyone has their era and today’s era is inclining towards Kotlin programming Language.

      Atomic CSS - what is it and is it useful?

      Atomic Design, or Functional Design as it is also referenced, is a bit of a weird beast. On one hand, it is a programmatic shorthand feature that allow you to use short code in development that then render CSS based on that, but it also a philosophy of sorts on how to organize CSS. A philosophy that very much resemble the inline-css era of old.
      The problem statement
      I think this statement says a lot on how ACSS and to some degree Atomic Design itself see the world of CSS. Anyone working with wild or free CSS development can certainly recognize some of these pain points. This is not uncommon in scenarios where many developers work in the same project or you have to work on top of a not so well-designed product.
      The question is, though, how many still work in that way and why?
      In a scenario where you have a defined design pattern, which should be the norm these days, this is rarely an issue. Regardless if you do atomic design or component design, your styles should be easy to maintain and define. Despite this I still see a lot of JS developers adopt inline styling and duplication of CSS in components. This is more common in libraries like React and Angular, I feel (personal experience, no real numbers to support that).
      So it is not surprising to see a rise in areas like Atomic Design or ACSS since that help bridge the gap in skill levels some JS developers have and the inherent despise we have to spend more time than we have to on things we don't really enjoy doing. Not to mention, there are some benefits that should not be overlooked.
      ACSS - Atomic Design as a preprocessor
      ACSS is a preprocessor that will transform inline HTML variables and create CSS from it. It has a fairly simple syntax and it works by looping though the HTML and scrape up the variables and then make a CSS file from what it finds.  In many ways, this is similar to inline CSS, but you would get a static CSS file instead of just printing it out in a style tag.
      If we borrow an example from the excellent CSS-Tricks site that I highly recommend you check out, then here is a snippet of code where we declare some classes and input a variable to each.
      <!-- Programmatic Atomic CSS Example --> <div class="Bgc(#0280ae) C(#fff) P(20px)">Lorem ipsum</div> The output from this would then generate the following CSS:
      .Bgc\(#0280ae\) { background-color: #0280ae; } .C\(#fff\) { color: #fff; } .P\(20px\) { padding: 20px; } This may seem quite useless compared to a well-defined CSS with variables declared that I could just input, but you could use both of course and use this to override in certain situations. Similar to how you would use inline styling.
      The biggest benefit of this however is that the CSS generated would be as small as you could make it. This is because the CSS would be based only on what can be found in the HTML. This can be useful for development in for example Angular and React, where I assume this is mostly used.
      In situations where you have classes reused over many components, like this website however, that would not really be as beneficial as having multiple CSS files is never a good thing and you would see duplication of classes. This is of course if you generate the CSS on a modular basis, but not if you render it globally on load somehow.
      Overall, I do not see any need for me working with sites like Invision Community and I feel it would not really work well in an atomic design situation with defined styles in both the UI and the HTML/CSS that is reused across components.
      I may be completely wrong about that, as I have not tried it and if so, sign off in the comments to tell me I am wrong 🙂
       
      Atomic Design as a Philosophy
      The idea of Atomic CSS is simple and, to be honest, not very new. The idea is to create single attribute classes and then stuff the HTML with them. Kind of like you would do using Inline styling, but with a global definition of the styles. It would look something like this.
      /* naming utility classes */ .relative { position: relative; } .mt10 { margin-top: 10px; } .pb10 { padding-bottom: 10px; } I say that this is nothing new because this has been around since before inline styling even existed. One reason it is not widely used is because it makes the HTML cluttered and hard to read. It is also a bit annoying to work with compared to having well-defined CSS classes as you will have a ton of attribute shortcuts basically rather than a library of styles.
      If you are used to working with frameworks like bootstrap, then you are already familiar with the concept, since those frameworks also have libraries of smaller styles that you can mix and match. Atomic CSS is much smaller however and rather than having for example a flexbox class that have the standard values you use all over the site you have to build those up with a set of classes inline in the HTML.
      Is it a terrible idea?
      Atomic design as a concept can be traced back to October 2013 and an article written by Thierry Koblenz. It has since evolved and you will often see it in reference from the new breed of JS developers that work in frameworks like React and Angular. While it may be a bit unfair to say that these new JS developers do not have that same deep understanding of CSS as the "regular" front end developers, I do see this distinction growing.
      For the JS developers however, this is pretty useful as they can focus on function rather than form. You have probably seen the mess that sometimes happen when JS developers mix inline styling, component specific styling and global styling. It is as bad as having multiple novis CSS developers trying to use EM when they do not control the output containers...
      I hear some arguments that this makes it easier to avoid specificity issues, but I do not agree with that. If you control your code, then you are a pretty bad developer if you can't handle your classes properly. It all comes down to planning and setting structures after all, unless you are just playing around like I do on this site.
      I digress though and to answer the question if this is a terrible idea I think there are use cases for when this can be useful. Since that article in 2013 however, I think those use cases are less now, especially with the introduction of CSS variables. I do however think there is a very good case for using this same idea for defining variables and to keep your classes small as a philosophy.
      I do think there are certain scenarios where it is a good idea to use the concept of Atomic design, and that is for overrides. Things like fonts, colors and spacing can be useful to sometimes just make a small adjustment rather than building new components.
      Also, if you generate your content at runtime on the server, there are benefits to this since you can combine it with CSS-in-JS to dynamically generate very small CSS files. I guess this is why React and Angular developers are liking this way to organize your CSS classes. You can still do this working with regular CSS, but the files will be bigger since you are bound to have duplicate attributes in your classes.
      So it is not a terrible idea, but it comes with some issues.
      Allow me to explain...
      My Thoughts
      While there are benefits in some cases, there are some negatives as well. The biggest issue for me is that while we reduce the CSS, we instead increase the size of the HTML. The HTML also becomes much more cluttered and harder to read because unlike CSS where we can group classes, or even split them on multiple files, HTML will just be one big garbled mess.
      Consistency is also an issue because the idea of recreate clusters of classes to achieve the components is done manually every time, then you will see consistency go out the window. We see this all the time in wild or free CSS, where pretty much every component have its own class styles uniquely. This is especially problematic if you have JS developers that are not very good at using CSS and you try to set up a design library.
      At the end of the day however, front-end developers are flexible and resourceful people. All of these potential pitfalls can be managed and if Atomic CSS works for you and those that you collaborate with, then go for it. Just don't make the decision just in the development team as you need to work well with both Design and Test so they should have a say as well. Also, your way of working must work across teams, so don't start using Atomic CSS if you at any time will have other teams working in the code as well.
      You know all that of course, but it is something that you can never repeat too many times.
       
      Do you use Atomic Design today?
      If you do, what benefits and pitfalls have you uncovered?

      How to make realistic estimates when working with software development

      Estimations for software development seem to be the bane of almost every company, but why is that really? Why is it so difficult to approximate the time and effort required when we do this all the time? There are a few reasons and in this article I will go over how I do my estimations and give you some of my experience on how you can maintain a 90% accuracy in any project.
      For a good estimate you need to start with one very important thing: define if you estimate based on time to complete or  time to deliver. These are very different because the time to deliver will be substantially higher and much more prone to variations. This is because in the daily work you will be dragged into meetings, have people distracting you and so on. For good estimations we always estimate on time to complete as our basis.
      Stop doing happy estimates
      The worst thing you can do is making happy estimates. These are estimates based on the utopia that everything will work smoothly and you will be left in total isolation to focus. It never happens and Murphy is always present. Happy estimates may seem good because the product owner love low estimates, but they hate when you fail to deliver.
      Happy estimates usually happen when an architect is stressed and throw out a guesstimate on the fly. It will almost always bite you in the butt because not only will everything seem easy to the architect, so they will underestimate it, they also never consider Murphy.
      You do not estimate to be nice, you estimate to give a realistic view on when something can be available in production. If you have a hard time to stop making happy estimates, then implement this very simple rule:
      "Any time that is needed beyond the time you have estimated you will do in your own time without payment"
      Take your time doing estimates
      An estimate is not a guesstimate that you throw out on a high level requirement. An estimate is your promise on when you can deliver and as such you should take your time and think that through. Don't sit around doing arbitrary guess work in a planning poker or play with t-shirt sizes unless you want to avoid doing any estimates at all. That type of guesstimating is for high level requirements, so make sure they stay there.
      Break down the requirement and use your experience to guide you to a first number in your estimation. This estimate is how long it will actually take to sit down and build based on the requirement. Make sure that you ask questions to clarify where needed so have the information you need. This is also a good time to start working on a solution design to make sure you have considered things that may not always be apparent. For example validation of data in integrations or extending a JavaScript validation for a new form.
      When we have done this, the number is still wrong, but we need it as a starting point.
      Add the things you forgot
      Now that you have done your estimate, many think they are done. That is rarely the case, so let us add the things that is not included yet. The most obvious problem that I see a lot is that the estimates is usually done by the most experience person, which also usually is the one that work fastest of everyone in the team. So what we do is to look at the estimate and the team, then we adjust based on what the slowest person in the team think is appropriate. This way we know that the base estimate is reasonable for everyone on the team.
      The second thing we do is to consider Murphy. Things always happen and based on the complexity we increase the estimate with 20-100%. Not having room for mistakes is in itself a very big mistake. It will almost always happen and if it does not happen for this particular task we will either be able to resolve things faster than expected, or we have more time for other tasks. Either way that is a positive thing.
      The third thing to look at are testing. All code should have unit tests and it is often forgotten in the estimate. You also have non-functional requirements such as loading times and browser support that you must consider. As a developer you are also responsible for testing the code and this should be added as a second estimate. For many estimates this alone will add 20-200% or even more to the estimate. This is especially true for frontend development where you often have 18+ variations just for devices and browsers.
      These three very simple things easily multiply the original estimate two to three times.
      Now let us consider your efficiency!
      A factor that is very often overlooked is efficiency. No person in any team will ever have 100% efficiency in the sprint. I do not mean your focus level during the day, even if that also is a factor, I am talking about those pesky things that break your concentration. Things like meetings, stand-ups, code reviews and all those "I just want to ask a quick question", cost a lot of your time during the day. In my experience most teams will have an efficiency of around 40-60% depending on how often they are disturbed.
      Depending on if your product owner understand estimation or not you can choose if you add the efficiency in the estimate, or if you have that as an external factor in the sprint itself. If you are new to this part of the estimation I suggest that you start with 50% efficiency and then adjust over time as you get better at estimating your efficiency.
      With this step we now add a second two time multiplier and you are now close to a realistic estimate.
      This may seem like a lot
      This may sound like the estimates always will be very high compared to how you are working today, and you are right. This is why you always feel stressed and why you fail to deliver on promise in every sprint. It is why we invent things like story points to mitigate our inability to take responsibility for things we can't estimate properly. Realistic estimates are just that and if your estimates are far lower than what you get doing estimates this way, then remember this very simple rule:
      It is always better to overestimate and over deliver than to underestimate and under deliver.
       
      The Quick Summary
      Make estimations in actual time to complete, not arbitrary measurements. Take your time to understand the task at hand and stop guesstimating. Adjust the estimate to fit the slowest person on your team. Add task for testing and make estimation separate for that. Remember that things always go wrong, so make room for that. Make sure that your efficiency is considered and calculated into the time to deliver.
      Making good estimates is based on experience and knowledge. This means that like other skills you can get better at it. If you constantly work with arbitrary measurements like story points and you constantly fail with no change to your estimation process, then you should stop doing that. Not only will you fail at a crucial part of your work, your inability to provide accurate estimates actually cause harm in the form of stress and frustration. It is up to you if you want to spend your time in constant failure or constantly provide estimates that are realistic and dependable.
      Learning to make good estimates is not rocket science, just common sense and experience.
      So start doing it today.

      CodeLobster IDE - free PHP, HTML, CSS, JavaScript / TypeScript editor

      In this article, we suggest you to get acquainted with the free editor of web languages - CodeLobster IDE. It is presented on the software market for a long time already, and it wins a lot of fans.
       CodeLobster IDE allows you to edit PHP, HTML, CSS, JavaScript and TypeScript files, it highlights the syntax and gives hints for tags, functions and their parameters. This editor easily deals with those files that contain a mixed content.
       If you insert PHP code in your HTML template, then the editor correctly highlights both HTML tags and PHP functions. The same applies to CSS and JavaScript/TypeScript code, which is contained in HTML files.
       The program includes auto-completion function, which greatly speeds up the programmer's work and eliminates the possibility of errors.
       

       
      CodeLobster IDE provides contextual help on all supported programming languages, it uses the most up to date documentation at this moment, downloading it from official sites. So we can quickly get a description of any HTML tag, CSS attribute, PHP or JavaScript/TypeScript function by pressing the F1 key.
       The built-in PHP debugger allows you to execute PHP scripts step by step, sequentially moving through the lines of code. You can assign check points, view the process of the work of loops, and monitor the values of all variables during the execution of the script.
       Other useful functions and features of the IDE:
      A pair highlighting of parentheses and tags - you will never have to count parentheses or quotation marks, the editor will take care of it. Highlighting of blocks, selection and collapsing of code snippets, bookmarks to facilitate navigation on the edited file, recognition and building of the complete structure of PHP projects - these functions ensure easy work with projects of any scale.  Support for 17 user interface languages, among them English, German, Russian, Spanish, French and others. The program works on the following operation systems: Windows 7, Windows 8, Windows 10, Mac OS, Linux, Ubuntu, Fedora, Debian.  The professional version of CodeLobster IDE provides the programmer with even more features.
      For example, you have an opportunity to work with projects on a remote server with use of the built-in FTP client. You can edit the selected files, preview the results and then synchronize the changes with the files on the hosting.
      In addition the professional version includes an extensive set of plug-ins:
      Fully implemented support for JavaScript (and TypeScript) libraries, such as jQuery, Node.js, AngularJS, AngularTS, BackboneJS, EmberJS, VueJS and MeteorJS. A large set of extensions that help to work with PHP frameworks - CakePHP, CodeIgniter, Laravel, Phalcon, Smarty, Symfony, Twig and Yii plug-ins. Plugins for working with the most popular CMS - Drupal, Joomla, Magento and WordPress. Also CodeLobster IDE has special plug-in for Bootstrap.  
      We can download and install any framework directly from the program without being distracted from the main tasks.
       In general, for a year of work, our team had no complaints against the editor. CodeLobster IDE works fast, does not hang and allows us to work even with large PHP projects.
      You can download CodeLobster IDE from the original website:
      http://www.codelobster.com/

      10 Questions You Should Ask When Hiring a Magento Developer

      Magento is one of the most popular e-commerce platforms that are out there, famed for providing no limits when it comes to customizing your online store. Whether you’ve decided to build your store from scratch, wish to optimize or migrate the one that you have, you won’t make it without some professional help of specialists. In this article, we give you tips on how to hire expert Magento developers and which questions to ask them.
      Tips on Hiring Magento Developers
      Before stepping to the questions, it’ll be helpful to know a couple of things about the process.
      There are many specialists all around the globe, and you need to know who you’re looking for as the developer services can differ based on what you need: migrating the store, building it, optimizing it, etc. Having a clear vision of what you need specifically makes up almost half of the deal. Make emphasis on experience with similar projects to the one that you’re planning, this can eliminate some unneeded questions or blind spots. Keep in mind the time-lag if you’re hiring someone on the other side of the world. Which Questions to Ask a Magento Developer
      Now that we’ve given some general recommendations of where to look for Magento developers and what to keep in mind as you’re searching, let’s move on to the actual questions you can ask and why you should do so.
       
      1. How many years of working with Magento do you have?
      Speaking about Magento development, the experience of actual work on the platform is the key factor to pay attention to. Because Magento isn’t easy to get in the hang of, it can be challenging to understand and master even to those who have many years of general development behind their shoulders or to those who are good at PHP.
      The more years of hands-on work that the developer (or team) has with Magento the better. The reasons for that include the quality of code that is produced as well as the wider range of tasks and issues that could be taken care of. Importantly, make sure those who you’re considering to hire have plenty of experience with the Magento 2 platform, as Magento 1 (the previous version) differs from it big time.
      That said, you’d surely want your developer to know how to sidestep a problem, avoiding it before it even arises, as well as to have the necessary knowledge to fix things quickly and efficiently in case something goes wrong. 
       
      2. Are you Magento certified?
      To be fair, having Magento certification is not an obligatory requirement. Yes, on the whole, certification is a big plus since it somewhat proves that the candidate has the needed knowledge, and that he/she took the time to confirm having it. Nevertheless, although there are many types of Magento certificates out there, some of the questions that the tests include to get the certificate are outdated and don’t cover the recent turns such as PWAs (Progressive web applications).
      So, if the person in front of you is officially Magento certified, that’s wonderful. If not, that shouldn’t become a ground-breaking reason not to consider them for the job, especially if they could boast having plenty of Magento 2 experience under their belt.
       
      3. How well do you know Magento 2 architecture?
      As mentioned earlier, Magento isn’t a piece of cake. This question is especially relevant if you don’t understand which Magento (1 or 2) the person who’s before you has worked with. Magento 1is becoming outdated, and everyone is either making the move to Magento 2 or building ground-up on it. Consequently, it is vital to dot the “I’s” regarding where the candidate stands in terms of Magento 2 architecture knowledge.
      Like already stated, Magento 2 architecture is radically different from Magento 1. It’s quite hard and time-consuming to figure it out too if you’re just getting acquainted with it (roughly, you need about a year to hold up well). This is why you should definitely be on the lookout regarding this. 
       
      4. Have you ever migrated a Magento 1 store to Magento 2?
      As you’ve probably guessed by now, moving a store that was created on Magento 1 to Magento 2 is a very complicated problem to solve. The thing is that in order to cope with the task successfully and within adequate time frames, the developer (or team of developers) should be equally witty in both of the platforms. They need to know M1 and M2 like the back of their hands, keeping in mind all the features and elements that the two differ in. They have to be able to carry out loss-free data moves, come up with custom solutions, deal with the compatibility of modules, among other things.
      Thus, if the candidate has migrated Magento previously, that could be a good sign. You may ask about what was challenging, how long the process took, and look at the website.
       
      5. Which progressive JavaScript frameworks do you know?
      What’s for progressive JavaScript frameworks, knowing React.js or Vue.js, for example, is noteworthy. Having such skills, developers are able to make UI components that’ll be reusable for sites and applications.
       
      6. Do you have experience with Magento’s PWA Studio?
      Progressive web applications are a highly popular and promising trend in e-commerce. Because the solution offers an affordable replacement for native apps and allows your website to work like an app (even offline), at the same time being fast, responsive, and accessible by search engines, it’s a solution that many store owners want to get ahold of. Ask your developer whether they’ve built PWAs and their thoughts on the subject.
       
      7. Which of your former Magento projects was the toughest/are you most proud of?
      Browsing real examples of work is yet another great option. CVs and portfolios might be packed with information, so fishing out some specific highlights can do you good. You can ask which aims were set, how were they handled. Pay additional attention to the points that are connected with custom solutions and configuration.
      On another note, make certain that the portfolio in front of you actually reflects the work of the specific candidate and that it’s authentic, you don’t want to waste your time on something that’s claimed to be theirs but really isn’t. You can attempt in contacting the company and ask them a few questions.
       
      8. If you were to give advice on Magento optimization what would it be?
      Let’s face it, if you’re running a business in the sphere of e-commerce, you want your online store to be performing at its best. Time is moving forward, technology is evolving, new trends are established. This means that you’ll need optimization so that your store is viable, fast, findable via search engines, provides a great user experience, etc.
      Some replies that can count here would surely include recommendations on optimizing website speed, improving the product search, and reworking the checkout. At times just several touch-ups can already make a change for the better.
       
      9. Do you provide support after the site’s release?
      Knowing that your developers will have your back after the release also helps. After all, if there will be a situation when you’ll need urgent assistance, having a service level agreement with your developers wouldn’t hurt. For this reason, settling from the very start the “what happens after the release” matter is in your interests.
       
      10. Do you mind preparing a test assignment?
      It is considered good practice to offer a test task to the specialist who you’re planning to hire. After all, it’s your chance to see the person in action. One of the ways to do that is to request to solve an actual issue that you have or to turn to specialized platforms that were created for test assignment purposes, for example, Devskiller.
       
      All in all, approaching the matter of hiring a Magento specialist for your project is very important. Ultimately, these people will be entrusted to deliver a product that’ll influence your business. We hope that this guide will help you when searching for your perfect match!
×
×
  • Create New...