I'll tell you my story as you did with yours, as a sort of knowledge exchange.
I work in a -for the time being!- small startup that has to cover every possible technical aspect there is out there, from x64 assembly to machine learning to web development, and I'm the only backend guy (but this will hopefully change soon), I currently work 12 hours/day, on saturdays, I do devops, release management, development, planning, mentoring for younger guys and a lot of other stuff. I have to manage a prototype inherited from someone else and manage its evolution to a mature system while at the same time keeping the first small production systems alive and well. I sometimes even touch frontend code (that I hate with all my guts). I'm even taking online courses meanwhile. What's my point? I simply don't want to find myself in the position of having to explain to "the management" my technical choices. It's simply not what I want to do. I want to fail on my own if I must, but as someone -maybe joel spolsky? I don't remember- once said: never work for someone who has never written a line of code. That said, I think that, especially when you're alone, the only tool that helps you is the tool you're familiar with. Time is essential. Sbt is a PAIN if you don't know it, while if you know it you can customize your builds to degrees maven users cannot even think of. The same applies to scala. The compiler is unbearably slow for someone used to java/intellij/eclipse (I come from there). You have to rely less on the IDE and learn to trust the compiler errors, I even disable automatic auto-completion because it's so slow, but anyway, once you go the "scala" way, if you know the tools, if you know the language, if you know a bit of theory (functional etc) and the idioms, a new world unravels in front of you, trust me. What I really think? On small/greenfield projects, process, automation and delivery tools are the most important thing, whatever build tool, framework and language you use. Software engineering and development changes radically when you have time and money. In the last two months I set up trello, slack, jenkins, gitlab, openldap, artifactory, a private docker registry (PAIN), ansible scripts, continuous integration environments, automated build, packaging and release of each and every component. I used akka-http on a small component and I intend to use it on a bigger one, I wrote a number of python scripts, shell scripts, etc etc. Using sbt native packager, for example I now have reproducible builds that create docker containers and one-click releases, builds and deployments. See it this way: once you have the infrastructure in place, changing your projects structure is like changing your code when you have 100% test coverage. If you structure the code well and all your process is automated, it's incredibly easy to change the build tools, so my suggestion is not to focus on those at the beginning. If you want to introduce scala into your projects, start with tests. You could have separate sbt projects with end-to-end and performance (gatling) tests written in scala, to try it out. Sbt is not necessarily slower than maven as you seem to think, you just need to leave it open, it's only the bootstrap that's slow. On the contray, on a number of occasions I had to write custom maven plugins or patch already existing maven plugins because of the limitations of the xml-based approach. Maven is so much easier to get up and running as long as the plugins you have cover all your needs. I have never used it with scala and I don't know the latest versions anyway. Are you able to split pom.xml in more than one file now? I like to have small, organized files for the build as well, I wouldn't use maven even only for the huge spammy-xml-ish pom files. I like the idea that the build is a project itself and not just a descriptor or the project. Sorry for the stream of thoughts and for going off topic...! On another note: is there anyone in this group who works in Singapore? If there is, can you contact me? thanks On Tuesday, 16 June 2015 22:14:53 UTC+2, Guido Medina wrote: > > Hi, > > This is not exactly a question, more like a discussion and sharing some of > my experiences lately, most of it for medium+ size companies might not make > much sense but for overloaded small teams with one or two developers doing > everything, here is my *-as short as I can describe it-* story: > > I was hired to continue developing a system, but such system was doing > anything and the premise was to use X asynchronous framework *-won't say > the name-* to build a high available and scalable system initially > with several Maven projects and Eclipse. > > Everything looked perfect until I discovered the project was a green-field > project with thousands of lines and it was not working so I decided to > scratch it, first I had to convince management that Akka was the way to go > and to do that I had 3 weeks to build a prototype that could deliver the > basic functionalities so I had to make quick decisions and learn Akka while > going: > > - *Development environment:* No doubt, IntelliJ, I was willing to buy > it myself if they wouldn't, I'm not too fond of SBT so I'm doing > everything > with Maven, my project is written in Java 8 but it has already the Scala > compiler so I can add Scala code if I want to, also IntelliJ Scala plugin > is good to look at API source code and stuff. > - *Project structure:* Maven parent project with modules, a common > module for shared data structures, utilities and messages, a very minimal > number of dependencies, for example I was using Jackson Json but there > were > like 4 jars so I switched to a lighter and smaller Jar - Gson. > - *Execution:* Each module is just a Java main with an ActorSystem, > common.conf from common module dictates general config that are included > into each module_name.conf > - *Akka cluster/remote:* The project was designed from the beginning > with location transparency and scale-ability in mind. > - *Execution inside IntelliJ:* Easy because each module is just a Java > main. > - *Maven profiles:* Help me create deployment options for different > environments like dev, test, uat, etc. > - *Maven runners:* There is a mirror project which has the same > structure as the main project but it only acts as script builder and > application assembler to create easy executables using Maven app > assembler, > due to all problems I have heard, I preferred not to use shaded nor fat > jars, instead something else generates the script (module_name.sh, > module_name.bat) for me so all I have to do is pass such scripts to IT > admin: http://www.mojohaus.org/appassembler/appassembler-maven-plugin/ > - *Location transparency and caches:* I have a sort of a address book > per module, each module instance subscribe to relevant cluster events and > when it does it knows *-by convention-* what supervisor it needs to > send a message to initiate the handshake, say a module named "strategy" > comes up, that module has the role "strategy" so I know at that node > address/user/strategy is a supervisor running, so I send my actor ref, > once > it gets it, it sends to me his actor refs cache -children- and then I have > a local cache with addresses, so if I need to locate some account ID, I > just look up by Integer in my cache and I get an ActorRef, or I could look > for a round robin router because some components are load balanced so each > other supervisor keeps a round robin router updated. > - *Dispatchers and mail boxes:* It wasn't easy to come up with a good > design initially, I was using the default dispatcher, now I have the > default dispatcher modified, a dispatcher for blocking operations, Netty > server and client pools customized, Kryo serialization > and SingleConsumerOnlyUnboundedMailbox, this is the aspect most of us will > spend most time, be ready for the inevitable consequences here, you will > play with these hundreds of times. > > > *Why did I make such decisions?* > > - Time wasn't in my favor, I wanted to use something that just works, > and location transparency + cluster + local caches is doing a nice job for > me. > > > *What problems am I facing now?* > > - Only few, now I have to build the UI of a system that it is running > in production making real transactions but I'm waiting on Akka HTTP's docs > for Java, yeah I know Scala is there but remember, time, Scala is on my > list and it is going to happen because I say so :D but not yet. > - Akka remote is not behaving excellently but I expect that to > improve, fortunately my project required max time of 5ms and my system is > doing from 1ms to 4ms with a caveat, first few messages take 50ms and > eventually *-sooner rather than later-* it goes down to within > parameters. > > *Moving forward:* > > - There were desperate moments because the old project took the > company 1 year plus the money spent and nothing was delivered so I was on > a > very bad position, I didn't know this at the interview but I moved > forward, > now management is very happy because magic happened, so thank you Typesafe > for producing Akka, it helped me focus on the business logic and not on > the > technical details *-yeah, people who knows me will say, you, not > worrying about micro optimizations?-*, this time I needed something > that allowed me to be practical and fast and Akka did it. > - Monitoring, I think we will go ConductR route, but still I need to > produce the rest of the system so that we can monitor *a system.* > - AngularJS + Akka HTTP for REST and web sockets, because my project > is mainly beta, when I'm done I hope they are kind of optimized. > > > And now I will stop writing, it has been a long day *-the last 4 months > every day has been a long day-* > > Hope this helps you when starting your Akka project, this also applies to > Scala btw. > > I have been developing this project using a company's laptop which only > has 8GB of RAM, spinning disk *-why not a SSD !!!-* and there I have to > run IntelliJ + several JVMs + database so you will find Maven more > beneficial than SBT for such purposes *-at least when using it built-in > with IntelliJ-* > > *Note:* I'm a non-English native speaker so you will find some non-sense, > more likely a bunch of ideas put together like a big Spaghetti plate. > > Best regards, > > Guido. > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
