WebSummit 2015 is a tech conference for geeks, this time it was organized in Dublin, Ireland.
The well spotted summary of WebSummit 2015 edition might found here: https://medium.com/@kingscooty/web-summit-2015-a-developer-s-perspective-c490c0048ad4
I encourage you to read it – it’s only 7 minutes long.
TL;DR from that article: WebSummit speakers are not attending to wow developers and creatives, they’re here to impress business owners. It’s that simple. Web Summit might be great if you’re a startup and you’re looking for investment.
I’m software developer experienced in writing webapps on jvm. What, a guy like me, might be looking for at such a conference – touted as `Davos for geeks`? Maybe some leads (except a few interesting talks – Bryan Lilies, Alistair Crolls). Conference was huge. I usually attend developers conferences up to 1k of people, this one was massive 30k attendees. I had an amazing time in Dublin with my teammates, every evening we joined night summit to make a new friendships. As a neophyte salesman you wish to talk to each and get know every single story but it’s simply impossible and unfortunately you have to live with that awareness. After a first few talks you got an impression that you are all around amazing talents with amazing ideas and products. Read more »
Code4life.pl is 100% Free Roche Software Conference. Invited speaker guests were: Dr. Venkat Subramaniam, Greg Young, Dino Esposito.
Adam Waltman from Roch Poland gave an interesting welcome speech, I could comprehend about internal IT Roche structure, and that price of sequencing DNA dropped from 100 mln $ since 2001 to 1k $ now (2015) and continuing that reduction in price. Basically sequenced DNA is a 3 GB file. Scientists do parental test comparing DNA of parent and a child. Except that they can give more precise predictions to inclinations of illnesses like cardiovascular diseases and cancer. Would you like to give this information to insurance companies for free?
In Dr. Venkat’s talk “The art of simplicity”, he pointed too much complexity around in our industry out. It’s hard not to agree with him. Dr. Venkat. He cited a talk of two interns after completing internship: “Dude, that company was awesome, I didn’t understand any line of code there”. What obviously is bad, bad practise. How expensive is that code to maintain in terms of time and recruitment (only the brave ones)? How fast can you find/fix a bug in that code? How big is bus factor? How big would rotation be in dev/ops teams then? Presentation included nice quotes: Read more »
This year I’ve attended Principles of Reactive Programming course. It wasn’t easy one, at least for me.
I mean, first two weeks driven by Martin were clear and straightforward. Even first Erik’s week about Future was approachable. The rest -rxScala with it’s Observables and actor model with Akka was rather hard and required a lot of work. My conclusion: akka isn’t easy concept (contrary to all akka guides saying it is) maybe it’s easier to debug when things go bad comparing to standard java locking/synchronisation model but for designing it requires a lot of time and hard work to acquire that way of thinking.
Except videos on course pages I red other helpful materials like:
- Learning Concurrent Programming in Scala book by Aleksandar Prokopec
- The Neophyte’s Guide to Scala
and two cheet sheets dedicated for this course
- by sjuvekar
- by dnvriend
And good akka tutorials
- Concurrency and Fault Tolerance Made Easy: An Akka Tutorial with Examples by Diego Castorina
- Reactive twitter app with akka by Jan Machacek
- Implementing the Reactive Manifesto with Akka by Adam Warski – video
Maybe someday that materials would help you.
[Title might be misleading because you need to make somewhere that merge but let it your github/stash/bitbucket etc. do it for you]
Problem: When starting your adventure with git did you feel like not knowing what is going on and ending with deleting the repo and cloning once again? I wish to help you and show how to work with git without removal&clone again.
The idea comes from Advance Git video. If you want TL;DR carry on with reading.
Once upon a time my dear friend told me how to work with git. Since then I’m happy git user and then I saw above video confirming that way of work. Before that I was blandly merging, pushing, forcing and always left in conflict state. There are some rules worth remembering in this workflow style.
1. rebase only
2. always work on a branch, even if your projects doesn’t require it
That’s it. Have a pleasant life!
The first one keeps your history clean – one straight line, because while rebasing to any branch you “plug out” your commits, rewrite new commits (from branch you rebase against) and apply your commits on top of that!
My typical work flow with git:
git clone [repo]
git checkout -b dev – always work on a branch, let it be dev
git add . & git commit -m "whatever" – commit changes, I prefer `git cola` for previewing and commiting my changes
git push origin dev – if you want to make an pull request you need to push your changes to remote repo
git checkout master – switch to master
git pull --rebase – pull new commits to master, let your local master branch be always a copy of that remote
git checkout dev – switch to dev
git rebase master – apply changes from master to your branch, conflicts may appear here, but after resolving you are synchronized with current master
git push origin dev:master – this pushes your commits from your local branch dev to remote master, instead of merge, or when working with PR let it github do merge
git branch -D dev – delete branch, repeat the process
By “resolving conflicts” I mean edit that conflicted files manually and applying with `git add` them and git rebase –continue. After 8 step you can push your changes to remote repo and it will be easily merged into master, or locally you can switch to master and merge your dev branch as well.
Shortcut for steps 5-8:
git fetch origin
git rebase origin master – being on dev branch
- for moving commits between branches use git cherry-pick
I like squashing because it makes feature come in one commit, but this is quite controversial, most prefer to make a lot of smaller commits claiming that it will be easier to revert or spot a bug.
- after a few hours of work you’ve got 2 commits, go and squash them
git rebase -i HEAD~2
- manage two steps
- you’ve been shown a history in reversed order so you mark `pick` first commit and mark `s` or `squash` the rest, save & quit
- on second screen you delete or comment out commit messages and leave just one
- you could refresh your master branch by pulling changes like in step 2., after that please get back to
git checkout MyDevPolygon
- rebase your changes to master by
git rebase -i master
- you will be shown your squashed commit ready for commits, if git tells you about any conflicts, you will have to resolve them but only once!
Sometimes people are working on branches to which they merge changes from master (acquiring new design)… in the end they go back with their work to master.
In this common case you might need to apply one of following scenarios:
- BEST: always keeping your changes on top – rebasing to master while working on feature branch
- when you messed smth up and git asks you to resolve same conflicts over and over go and use
- at the end squash your changes two one clean commit
I love this article git team workflow merge or rebase
I’ve been in Luxembourg on AWS training for developers. It was free. The agenda
Day 1: Getting Started
- Working with the AWS code library, SDKs, and IDE toolkits
- Introduction to AWS security features
- Service object models and baseline concepts for working with Amazon Simple Storage Service (S3) and Amazon DynamoDB
Day 2: Working with AWS Services
- Service object models and baseline concepts for working with the Amazon Simple Queue Service (SQS) and the Amazon Simple Notification Service (SNS)
- Applying AWS security features
Day 3: Application Development and Deployment Best Practices
- Application deployment using AWS Elastic Beanstalk
- Best practices for working with AWS services
Maybe worth taking away was this security feature of giving and EC2 instance a ROLE, what would keep your source code clean of any secret credentials. (I still don’t know how to inject credentials into app without keeping them in source repository – automatically add credentials to system envs howto?)
Every module was ended with lab where we had to implement a solution for given AWS service. Everything was prepared very nicely.
The main drawback of this training was luck of lunch. I don’t know if this is common practise on west but in mine part of Europe it’s not. It seems just rude to me. We are paying high bills for their services and they can’t afford lunch on trainings?