We're definitely the "multi-thread guys" lol :D On Wednesday, 17 June 2015 00:01:13 UTC+2, Guido Medina wrote: > > Streams of thoughts are what evolve us ;-) > Yeah, I had to do some old school tricks to get the project to stage it is > atm, but things will change, the company mindset is changing very fast, I > have my good effects on management that nothing is impossible, we are > hiring another person more UI oriented so if anyone Java 8 or Scala is > interested on a very peculiar system that I started for the Financial > Industry in Dublin, Ireland, just let me know, I need a partner :D > > My background is similar to your, I'm the backend multi-thread async guy, > I hate UI... > > Thanks for sharing, it is always good to know others experiences, > specially small teams. > > Best regards, > > Guido. > > On Tuesday, June 16, 2015 at 10:48:23 PM UTC+1, Giovanni Alberto > Caporaletti wrote: >> >> 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.
