Hello, everyone. My name is Maria Corina. And today we're gonna talk about tools and frameworks um how to, to accelerate front and development and to motivate my, my point to you to prove my point.I've brought up an African Proverb which says that every day when gazelle wakes up, it knows that it has to outrun the fastest line um to stay alive. And the lion when it wakes up knows that it has to outrun the slowest gazelle in order to have some food. So whenever the sun goes up, um you know that you'd better be running and this applies to the market as well. So we need to accelerate from uh deliver software de delivery um so that we can address earlier adopters of our product. It also guarantees better planning for us because we have more time and more buffer if we are moving faster. And um it also minimizes the risks, risks because we can follow with fail, fasting, uh uh uh failing faster so that we have time to um try some new features or do some A B testing. So it, it helps us to test our product better and deliver the final version of our product faster. Um But of course, if we just um are faster, it doesn't mean that we stop. Once we're done, we just can start further products early uh projects earlier.

So we are actually doing more and the last but not the least, sometimes you have to be fast just to survive because everything that I've mentioned before also applies to your um competition partic particular for F is that you might know that we are getting some javascript frameworks uh frameworks now and then so you have to be fast to keep uh to stay updated, to stay up to date before we move into um uh go into deeper details on tools and frameworks.

I'd like to briefly introduce myself. I am Maria Kieva, I write articles on web development and in particular on Angular for NGO and I am also co organizing NGDE. This is a uh the first community based Angular conference in Germany which will take place in Berlin in October.

Um and professionally, I'm working as front and technology lead at Dale Solutions. It's a small company based in Germany. So if you have any questions regarding my talk regarding some job opportunities, feel free to connect, feel free to drop a line uh via email, Twitter or linkedin and you see my contacts in here. But let's move on and let's talk about tools and methods um how to accelerate front end development development. That that's what we are here for, I've brought several of them, we'll start with something which is really close to the code itself. First of all, we need some code formatter in this case, pre is in the industry standard and in front end it's, it's particularly relevant because we have a lot of html and when it's proper formatted, it's easier to uh mention uh to, to see, to spot some missing closing tags, for example.

So um this is also a great tool for some consistent formatting. If the same framework is applied to format your code, when you look at the code of your colleagues, you uh find your way through faster, meaning you, you can develop and um extend the code of your colleagues faster. The next tool is um or the next uh concept um in here is the static code analysis since we're usually working with javascript and this is an an interpreted language. Uh The problem is that um we don't have the support of the compiler, we have to um analyze our co statically before we have the runtime errors to prevent that. Those um For this um we can use linters ESL is the industry standard for this, but you can also use Sonar cube additionally um for some quality gates or maybe also security checks. Here is an example of the linker which helps us to avoid some typos. Um For example, with local message or some type mismatches. If you use typescript, for example, and you check those errors before you ship your code, meaning that you deliver high quality software faster and don't spend time uh for debugging bug fixing, etcetera. The next one are module bundlers.

Um And this goes into the direction of writing code conveniently. Um when we develop, we write code, a human readable code. An example of this is here, you split your code in some meaningful logical chunks and put it there. While the bundlers make one long unreadable file out of this, the same applies for unifying angl finding those are the tasks that actually you wouldn't even be doing if those bundlers were not there. Task runners go in the same direction, they automate some of the code related tasks.

So we're moving away from the code. Um But we're doing some co related stuff, for example, with N PM scripts or, or the library called Husky, that's one of my favorite. And here you see some examples. So you can um run some tests, you can remove your disc folder, you can remove your node modules. And with Husky, this is a library which allows you to hook in into the G hooks and then you can perform some ransom scripts on the, on those actions on those hooks. For example, you can um uh run N PM install when you check out a branch or you can run your tests before you commit them to make sure that your code um is tested linted formatted before it ends up in the main trunk. Here goes the ID plugins and scripts. So we're moving away from the code level. And in here, um it is again the consistency that um supports us, we can um have a file with recommendations for visual studio code plugins, for example, so that the whole team has the same setup and we use those plugins um As for example, as language support plugins.

Um so that we have nice auto completion features or some additional checks or some um our imports are auto um like are sorted the same way so that we have the consistent code on. And we have uh some development enhancement that we get from our ID. And we can also use some code snippets if we are running, uh if we end up writing the same code again and again, we can make it a snippet um and um avoid copy paste areas with this. The next point are frameworks. Um We are facing the same problems in web development again. And again, that's why there are some clever people that came up with some ready made solutions. Um And by using some uh those frameworks, you don't have to re invent single page application mechanics from scratch. You, you don't have to make this take care of routing yourself. You can reuse already existing nice web components. You don't have to sell your tables or to implement some um way to sort it. Um So um using framework means you don't re invent the wheel, you save time by reusing something which is already there, which is tested by the community. So this helps you to speed up your delivery process. The same is valid for design patterns in here on the on, on the one hand, you are using best practices of the um community so that you don't spend time trying things out testing, debugging, finding out how to solve your problem. That's the first point.

And the second point is also that um by using those um concepts, it's easier to communicate it to your team members. So if you, if you say that you are gonna use a single drink here or a bridge or a factor, you know what problem you're addressing and you know how you're addressing it and your team members, if they know those patterns, they also automatically understand what, what and why you're doing here.

So this is a, this is end point which helps you to um re invent to, to do not re invent the wheel, but also to improve your communication, make, making it more efficient. Um The next point is about processes, processes are, is like the software delivery is the process itself. So that's why you cannot do without it. And you can enhance that by some uh automation or some it tools. If you're using Jira for your software delivery process, you can also add some plugins which could for example, um run the tests automatically and um connect to the pipe to your pipe, read the results of your tests and uh play it back to the tickets so that your tickets are updated automatically with the test results.

This is possible and then you don't have to wait for the developers to update the tickets uh to move around to uh track it. So this is um a feature which helps to um speed up the management process around whole delivery. Another example in here is alerting. Um For example, if you're using SP plank, you can write some alerts which um give you the nice fast feedback loop about what's going on in production or even in the chess environment so that you can react faster. So by this, you are waiting less till you spot some problems. You don't wait till the customer emails you or even change switches to the competition, you can react faster, you can fix it faster and you can move on with further features faster. The next point is front and specific. Sometimes um you don't have to, you don't want to may um wait for um the back end implementation if the back end is not yet there. Or maybe you have some test um user um configuration which is so specific that it's really hard to get, but maybe it's all about uh P you of some front end um framework. Then you don't need or you don't want to have any back hand. In this case, it's really convenient to have a fake one. My favorite one is Jason server though. You have several options. You have some API S which are hosted somewhere. You can hard code some values. But in here I'm really a fan of Jason server.

This is a small library. Um And here you see the whole code, it's like 13 to 15 lines of code. And with this, you can spin up the whole fully fledged server which can give you any response code, you can test for errors, you can get any mock data that you wish to get. Um And this gives you the freedom um and uh by decoupling the two signs of the implementation so that front end can move, move on faster. The next point is testing. And I know when we write some tests, we do not implement some features. So, um however, um tests enable us to um check the regression of our application and also the integration of some parts so that um when we test before we ship with spare time, debugging and production with spare time of uh some hasty um fixing, uh back fixing, etcetera. So um actually, this is a kind of no brainer if you wanna deliver your software, high quality software in a sustainable way. And this is the key point here, you have to test it before and test it continuously speaking about continuous processes, we finally at the continuous integration, continuous uh deployment and develop and delivery pipelines. Usually, if someone speaks about acceleration of software delivery, they start in here.

But you've seen that there are 10 other points um starting at the code level that you can do to improve your, to speed up your delivery process. But finally, we're here um here you can use any tool which is um industry standard Jenkins quite known, but it's been a while since this tool. Is there um any kids um um any any um portals that implement the GIT protocol, git lab, github, etcetera also provide uh some, some sort of C I uh by now. So one of the options would be um to integrate all these stages in there that I've mentioned before. For example, linking your code formatting your code, linking your code, testing your code, um putting it through the Sonar cube and finally building and deployment it somewhere.

So with the pipeline and again, this is a no brainer but um to make this whole presentation complete here you, it enables you to deliver the software faster in an automated way. Um be it to your test environment or to the production, but we're not done here. Logging is an important part. Um And, and this is why when you deliver your front end application, usually you don't know what's happening in the browser of your user if by implementing some logging solution using sentry or some other logging, putting your logs into supplying, you know earlier, what happens if something wrong goes on there and then you can fix it fa faster and then you have the tools to analyze it.

So when you have the locks from your client side, you have the information, you can fix the bug faster and then you can move on with delivering some features. Again, logging also contributes to, to um acceleration of the whole delivery process. The final two points are though and those are, in my opinion, the most important ones are people and practice. Of course, if you have a team of experts, then you're moving faster, but any team when practicing gets faster. So people and practice are the the key to success when delivering software because you cannot do it without them. And with this, we, we've arrived at the market and I'd like to summarize the key principles of the whole acceleration. First of all, of course, it's the automation.

So we wanna do less. We wanna automate our tasks, we wanna do uh when accelerate, we do, we want to do our stuff faster. Um However, we also wanna um um we wanna have the quality assurance because if we have this in place, we are redoing less, we're delivering from the first time and don't have to spend much, much time fixing stuff if we, we use already existing. So best practices and solutions, we are reinventing less and we have, we can save time on this point. And if we have some maintenance support in place, then again, we are fixing earlier. We are uh we are fixing faster and we can concentrate on delivery the last but not the least is the communication by this. I mean that we are waiting less. Um And we are um communicating more efficient so that we can um move on with the delivery faster. Uh We don't spend much time on figuring out what's going on and who is um who has to do what et cetera. So it's uh actually it's valid for any process in the context of acceleration. They all often speak about tennis developers. So this is someone who is um who is as 1010 times, as productive as other colleagues and delivering 10 times uh the outcome of the colleagues.

However, I usually prefer to speak about 10 X delivery process because um as you can see, it's not that you have a lot of uh points, frameworks, tools, methods and processes that you can um use and implement to speed up the whole process. And at this point there, um two or maybe three and key aspects that I would like to highlight. First of all, um you have to hold the whole system, you have to approach the acceleration holistically. It doesn't, it doesn't help a lot if you just have one of those elements out of in this case 14 without understanding um the whole having the whole picture. Um The second point in in here is that um those uh points or those aspects have to be applied um have to be relevant for your particular team and product. So if you are a team of full second developers, then maybe you might not need any fake backhand. If you're a single freelancer, then you might not spend that much time on um negotiation of code conventions. So it's up to your team to figure out what are the relevant acceleration points. And the last point is also about your soft skills. So um if you are not an expert in development yet, but you have excellent communication skills, then you can improve the whole process and still speed up by clarifying requirements in the first place and then you save time during the development process because you don't have this hope creep.

You don't have to renegotiate some features so you can um use your soft skills strength to save time during the development so that this is the last point in here. Um Appell to the soft, soft skill side of software delivery, which is as important as the technical one. And by this, we are at the end of my presentation. If you have any questions, please drop me a line. I'm happy to connect. Have a nice day. Do you have any questions

right now? Because we have a good time and I could

um answer them right now.

Thank you. Thank you very much for your feedback. I think I have a question. How would you identify te developed during an interview? That's a very good question. Actually. Usually I always look at the soft, soft, soft skills side. So I checked what were the problems that the, the, the person and how this person dealt with the, with the problems? Uh What kind of problems this person highlighted. So it's always about the motivation, the spirit of de development of soft skills of communication. Um Mm Said nice.

That's the biggest challenge. Oh Like the biggest challenge in my current pro uh project is for example, that we have the surrounding structures of we've been doing this all the time using the tool that is has been there since 10 years. Um and not switching to a new one which is faster or easier to use. So um it's kind of a months of trying to um tackle those acceleration points that we can tackle. For example, code conventions, os formatter, et cetera, but uh facing some problems uh using the tool um for this I CD which is not the best for our team. So that's the the current the biggest

challenge for me now.

OK. If there's no more questions, I'll check the links through um your linkedin profiles. I'm happy to connect and then once again, have a nice day. Enjoy further um sessions. Really interesting. Thank you for your time. Bye bye.