Sometimes there’s a need to fork a git repository and continue development with your own additions. It’s recommended to make pull request to upstream so that everyone could benefit of your changes but in some situations it’s not possible or feasible. When continuing development in forked repo there’s some questions which come to mind when starting. Here’s some questions and answers I found useful when we forked a repository in Github and continued to develop it with our specific changes.

Repository name: new or fork?

If you’re releasing your own package (to e.g. npm or mvn) from the forked repository with your additions then it’s logical to also rename the repository to that package name.

If it’s a npm package and you’re using scoped packages then you could also keep the original repository name.

Keeping master and continuing developing on branch?

Using master is the sane thing to do. You can always sync your fork with an upstream repository. See: syncing a fork.

Generally you want to keep your local master branch as a close mirror of the upstream master and execute any work in feature branches (that might become pull requests later).

How you should do versioning?

Suppose that the original repository (origin) is still in active development and does new releases. How should you do versioning in your forked repository as you probably want to bring the changes done in the origin to your fork? And still maintain semantic versioning.

In short, semver doesn’t support prepending or appending strings to version. So adding your tag to the version number from the origin which your version is following breaks the versioning. So, you can’t use something like “1.0.0@your-org.0.1” or “1.0.0-your-org.1”. This has been discussed i.a. semver #287. The suggestion was to use a build meta tag to encode the other version as shown in semver spec item-10. But the downside is that “Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence.”

If you want to keep relation the original package version and follow semver then your options are short. The only option is to use build meta tag: e.g. “1.0.0+your-org.1”.

It seems that when following semantic versioning your only option is to differ from origin version and continue as you go.

If you don’t need to or want to follow semver you can track upstream version and mark your changes using similar markings as semver pre-releases: e.g. “1.0.0-your-org.1”.

npm package: scoped or unscoped?

Using scoped packages is a good way to signal official packages for organizations. Example of using scoped packages can be seen from Storybook.

It’s more of a preference and naming conventions of your packages. If you’re using something like your-org-awesome-times-ahead-package and your-org-patch-the-world-package then using scoped packages seems redundant.

Who should be the author?

At least add yourself to contributors in package.json.

Forking only for patching npm library?

Don’t fork, use patch-package which lets app authors instantly make and keep fixes to npm dependencies. Patches created by patch-package are automatically and gracefully applied when you use npm(>=5) or yarn. Now you don’t need to wait around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.

Warm weather and cold Northern winds just call for a warm mug of cacao and something to read by the fireplace. Here’s monthly notes for February with topics from testing to software development project guidelines and from microservices to tips and tools. Also learning React App.

Issue 38, 19.02.2019

Testing

How to stop hating your testsI’m not a fan of extensive ui tests. I think they should be mostly about seeing that the whole system functions when all systems are integrated and functional. This talk makes a good case out of it. If you want to skip right to this subject, it starts around at 18:50 or so.

Software development

My Opinionated Setup for Web Projects“During the past few years, I have worked on multiple smaller and larger projects. In this blog post I explain my default project setup for a typical web frontend project.”

Project Guidelines“While developing a new project is like rolling on a green field for you, maintaining it is a potential dark twisted nightmare for someone else. Here’s a list of guidelines we’ve found, written and gathered that (we think) works really well with most JavaScript projects here at elsewhen.”

Microservices

Building Microservices: Designing fine-grained systems (pdf)“Distributed systems have become more fine-grained in the past 10 years, shifting from code-heavy monolithic applications to smaller, self-contained microservices. But developing these systems brings its own set of headaches. With lots of examples and practical advice, this book takes a holistic view of the topics that system architects and administrators must consider when building, managing, and evolving microservice architectures.”

Microservices vs The World“In the last 5 years microservices have been pretty much the topic on every architectural conversation. The idea is great, small, independent, cohesive, services that can be implemented, tested, maintained and released individually without much impact on the rest of the system. Microservices are then the holy grail of architectures all positives and almost zero negatives. If that is the case, why in the last 2-3 years our holy grail is getting bad press? Some engineers even suggest that a monolith is better. How can a monolith be better? Well, it all comes down to pros and cons and how the business is structured.”

Microservices architecture on paper sounds amazing but unless the business as a whole is not committed to it, then your department will end up with low morale, low productivity, and tones of code debt.

Tools of trade

DockStation“Application for managing projects based on Docker. Instead of lots of CLI commands you can monitor, configure, and manage services and containers while using just a GUI.” See running containers in histogram-type grapsh, monitor stats, connect with ssh to remote hosts, start/stop containers.

Scrolling inside ScreenDisable the alternate text buffer in the xterm termcap info inside screen so that you can use the scroll bars (and mouse wheel) to scroll up and down.

Something different

OWASP Helsinki chapter meeting number 36 was held 12.2.2019 at Veikkaus premises in Pohjois-Haaga. The theme for this meeting was about software security and the topic was covered with two talks and with a card game. Here’s my short notes.

What Every Developer and Tester Should Know About Software Security

The event started with “What Every Developer and Tester Should Know About Software Security” by Anne Oikarinen from Nixu. The main point was that information security isn’t something you can sprinkle over your applications – security needs to be baked in. Take security into account in every step of your software development process, focusing on design and development.

The talk was a great overview to software security and covered the topic from three perspectives: security requirements, threat modeling and security testing. It was nicely practical and theoretical and gave good tips to tools and how to approach the issue. The presentation slides can be seen on SlideShare.

Building security in: start with security requirements and threat modeling

Venn diagram of building security in

Follow standards and best practices

Use tools for improving software security yourself

Security in Agile Development

Joakim Tauren from Visma continued the event with “Security in Agile Development”and told how they manage security in large scale. The sofware security team provides security as a service to produc teams and utilize OWASP SAMM to empower teams. The in-house built system to manage security maturity matrix was cool.

OWASP Cornucopia

The event was wrapped up with OWASP Cornucopia – a live card game session. The idea behind Cornucopia is to help development teams, especially those using Agile methodologies, to identify application security requirements and develop security-based user stories.

The game plays like card game with six suites and cards from one to ace like normal deck of cards. Cards have security themed questions and the players try to answer in the given context if the issue at hand is a problem to be look into. In this case the context was Death Star themed with given architecture diagram.

But what does cornucopia mean? In modern depictions, the cornucopia is typically a hollow, horn-shaped wicker basket filled with various kinds of festive fruit and vegetables. In this context it would relate to can of worms :)

January is turning over to February and Winter with freezing weather and lots of snow has enlightened our days. Here’s some reading for the moments when Winter wonderland is too much and warm mug of coffee and fireplace is the place to be.

Microservices

X: "The Kubernetes consulting well is close to drying. The path to successful K8s/Cloud Native is clearer now"Me: *shows image below*X: "Can we have this conversation next year?" pic.twitter.com/oj0eYK0wL4

“To test the flow of a potential scenario, storyboarding and comics can really add an extra dimension that your users can relate to (or not) and provide feedback on the types of activities, thoughts and feelings they would be experiencing along the way. “

Privacy and security

“Interesting“ details in the thread and in the article ? Reads more like fiction but you couldn’t make this up with all the ways FB tricks users to gather data. https://t.co/XpGyhxdTip

Something different

The year has changed and it’s time for traditional retrospective of post done in 2018. By numbers 2018 was total of 23 articles which 11 articles were Monthly notes. I visited couple of conferences and some meetups, did software development and tested technology stuff. Business as usual and I presume that it’s going to continue this way also this year.

Monthly notes

It has been proved to be a good way to ensure that I keep reading what happens in software development and also think about it when I collect interesting articles to my Monthly notes series. The series continued with 11 posts.

Meetups

During the year I attended couple of meetups and if you follow me on Twitter you might have noticed that I went to more meetups than I wrote about. There are several interesting events in Helsinki you can attend almost monthly but you’ve to be quick to participate because usually events fill up quickly. But although the event seems to be full, there’s often spots left as some people don’t cancel if they can’t make it.

OWASP Helsinki chapter meeting 34: Secure API told about “Perfectly secure API” and “Best friends: API security & API management”. The event gave good overview to the topics covered and was quite packed with people. Eficode’s premises were modern and there was snacks and beverages. And also a sauna.

Have you ever wondered how to become a bug bounty hunter or wanted to organize a bug bounty program? OWASP Helsinki chapter meeting 35: Bug Bounty programs told all about bug bounty programs from hacker and organizer point of views with topics of “Hunting for bounties in a web browser”, “How to become a bug bounty hunter” and “Running a successful bug bounty program”.

In August I attended React Helsinki August 2018 meetup at Smartly.io. Topics covered “Splitting React codebases for increased development speed”, “Making your own Ignite generator – for React Native” and “Use GraphQL!”. There are links to recordings of the presentations.

Meetups and conferences are also nice way to both freshen your thinking, hear how other’s do things, get new ideas and meet people working in the same field.

Conferences

Last year there was lots of interesting conferences in Helsinki. In the Spring there was React Finland 2018 conference which told what’s hot in the React world. The two day conference covered topics of React on day one and day two was React and React Native. The two conference days were packed with great talks and new information.

Where the React Finland was a conference from developers to developers, the opposite was Red Hat Forum Finland 2018 which was held at Finlandia-talo. The mainline was “Ideas worth exploring. Come with questions. Leave with ideas.” The event was divided to keynote and to four breakout sessions. I chose to get hands-on with OpenShift.

The developer conference theme continued in Autumn with GraphQL Finland 2018. The first of its kind event in Finland brought a day of workshops and a day of talks around GraphQL. The event was organized by the same people as React Finland and it showed, in good ways. The talks were interesting, atmosphere was cosy and after party was bookie. All of the talks were live streamed and they’re available on Youtube.

Software development as usual

I managed to write couple of articles regarding software development and topics surrounding it.

Writing documentation is always a task which isn’t much liked and especially with diagrams and flowcharts there’s the problem of which tools to use. I wrote about generating documentation as code with mermaid and PlantUML as an alternative to crafty Draw.io. Using mermaid or PlantUML has the advantage that you can see the changes clearly in human readable text format and maintain source-controlled diagram.

A more practical approach to visualize things was when I did a build monitor with Raspberry Pi and touch screen. Information is a great tool in software development and it’s useful to have easy access to it. Using build monitor to show continuous integration status and metrics from running services helps you notice problems and get them solved quicker.

And as we know learning and staying current in software development is important and expanding your horizons can be achieved with different ways. One good way I have used is following different news sources, newsletters, listening podcasts and attending meetups.

Awesome times ahead

Years change but the blog stays pretty much the same. Also this year plans are to continue as before, write about technology, collect interesting articles, learn new things about software development and of course ride mountain bike.

Holiday season is soon here and it’s good to take a short break from work and maybe learn or code some new things while relaxing and enjoying the winter time outside. Here’s the monthly notes for December. Happy holidays!

Issue 36, 21.12.2018

Tips

Learning

Tips of ppl who want to learn
ReaktorNow Development Discussion campaign shared some insights in the field of software engineering. “Always keep learning and expanding your skills, and remember to step out of your comfort zone.”

A novice’s guide to learning to code with CS50
“CS50 is the best learning experience I have ever had in my life.” Over 12 weeks you get two hour lecture to watch and a problem set for you to complete each week. Start with Scratch, continue on C and move to Python plus HTML, CSS, SQL, JavaScript, JQuery and JSON. (from @walokra)

Security

Taking Down an Insider Threat
Excellent story about pentesting from the inside. And of great digital forensics and incident response team and meticulously implemented security practices.

Software development

Everything about distributed systems is terrible
Hillel Wayne 38 minutes talk at Code Mesh LDN 18 titled “Everything about distributed systems is terrible” talks about TLA+, formal specification system designed by Leslie Lamport. The claim is that you can find bugs in your (distributed) system by model checking that could be practically impossible to find with testing or in production.

Software development is one of the professions where you have to keep your knowledge up to date and follow what happens in the field. Staying current in the field and expanding your horizons can be achieved with different ways and one good way I have used is to follow different news sources, newsletters, listening podcasts and attending meetups. Here is my opinionated selection of resources to learn, share ideas, newsletters, meetups and other things for software developers. Meetups and some things are Finnish related.

News

There are some good sites to follow what happens in technology. They provide community powered links and discussions.

Podcasts

Podcasts provide nice resource for gathering experiences and new information how things can be done and what’s happening and coming up in software development. I commute daily about an hour and time flies when you find good episodes to listen. Here’s my selection of podcast relating to software development.

Newsletters

Normal information overload is easily achieved so it’s beneficial to use for example curated newsletters for the subjects which intersects the stack you’re using and topics you’re interested at.

The power of newsletter lies in the fact that it can deliver condensed and digestible content which is harder to achieve with other good news sources like feed subscriptions and Twitter. Well curated newsletter to targeted audience is a pleasure to read and even if you forgot to check your newsletter folder, you can always get back to them later.

Community chats

December is just around the corner but before that here’s monthly notes for November. More about leadership and stories, something about software development.

Issue 35, 13.11.2018

Frontend

CSS and Network Performance
What are best network performance practices when it comes to loading CSS? How can we get to Start Render most quickly? Good article of how your page will only render as quickly as your slowest stylesheet. And what to do about it. tl;dr; “Lazyload any CSS not needed for Start Render”, “Avoid @import”, “Be wary of synchronous CSS and JavaScript order”, “Load CSS as the DOM needs it”. (from @csswizardy)

Bash-it
Bash-it is a collection of community Bash commands and scripts for Bash 3.2+. (And a shameless ripoff of oh-my-zsh?). Includes autocompletion, themes, aliases, custom functions, a few stolen pieces from Steve Losh, and more.

Leadership

Managing with the Brain in Mind
“Treat people fairly, draw people together to solve problems, promote entrepreneurship and autonomy, foster certainty wherever possible, and find ways to raise the perceived status of everyone”. Good read about SCARF. (from @walokra)

On Being A Senior Engineer
What makes for a good senior engineer? tl;dr; Be mature engineer. Good read for everyone regardless of the line of business.

Seek out constructive criticism of their designs.

Understand the non-technical areas of how they are perceived.

Do not shy away from making estimates, and are always trying to get better at it.

Have an innate sense of anticipation, even if they don’t know they do.

Understand that not all of their projects are filled with rockstar-on-stage work.

Something different

You work to live, not live to work
Remember, your job is not your life. You work to live, not live to work. Work on what makes you happy and not burn yourself out. Thread has good tips to recognize it and take control. (from @jevakallio)

Have you ever wondered how to become a bug bounty hunter or wanted to organize a bug bounty program? OWASP Helsinki chapter meeting number 35 told all about bug bounty programs from hacker and organizer point of views. The event was held 6.11.2018 at Second Nature Security (2NS) premises in Keilaniemi. Here’s my short notes.

Notes from OWASP Helsinki chapter meeting #35

“Hunting for bounties in a web browser” by Juho Nurminen from 2NS started the event talks and told about how to approach the issue and showed some findings in details. For the usual of understanding the technology and focusing on what you know, it’s beneficial to read up prior art. Is it repeatable bug? Reproduce it in other context. The talk presented cve-2018-6033 (extension code can execute downloaded files), cve-2018-6039 (XSS in DevTools, privileged API can be overwritten) and cve-2011-2800 (data leak across origins). tl;dr; pwn things, submit crbug.com, profit.

In “How to become a bug bounty hunter” Iiro Uusitalo from Solita talked about bug bounty platforms and tips to be succesful. In short: POC or GTFO, recon, stay on scope, automate all the things, focus, report, wait, profit, join the community.

“Running a successful bug bounty program” by Thomas Malmberg from Hackrfi bug bounty program covered the topic from the “random dude from the other side of the table” point of view. “What really matters is finding bugs” but there’s a lot of things to manage. It comes to managing expectations of hackers and program owners. And remembering that hackers work for you (program owners) but they are not your employees.

Expectation management

“What really matters is finding bugs.” @tsmalmbe from @hackrfi told how to run a successful bug bounty program at @OWASPHelsinki meetup. Managing expectations of hackers and program owners. Remember: hackers work for you; hackers are not your employees. #OWASPHelsinki” – @walokra

The evening ended with a panel & discussion about bug bounty with Juho, Iiro and Thomas. There was lots of interesting questions asked and here’s some of them in short.

Hardware bug bounties, how to do if device not publicly available?

On premises hack days -> not so successful, too little time, concentrate on low hanging fruits.

How to choose [bug bounty] program?

Wide scope -> low hanging fruits.

What kind of reports of findings

OWASP Top 10 covers almost everything.

Everyone is scared of finding remote code execution.

Business impact findings.

Recon: who we are, what we do -> what has big business impact. Also where’s the legacy code?

Impact of how hacker and product owner sees findings? Owner will set the impact, how it should happen at both ends? how to define the final impact corresponding the value?

Always estimate, run some CVSS estimator.

Use Google’s approach.

Fairness and trust. Programs task is to create trust.

Awfraid of reporting found bugs when there’s no bug bounty program?

Program has rules which covers legal matters. Read the rules, ask.

Top 3 negative things?

Program runner went public, lots of bugs, hackers pwned whole system.

Communication issues.

Program runner: call on Friday night, database lost. bug bounty program to blame.

GraphQL Finland 2018 conference was held last week (18-19.10.2018) at Paasitorni and the first of its kind event in Finland brought a day of workshops and a day of talks around GraphQL. The event was organized by the same people as React Finland and it showed, in good ways. The talks were interesting, venue was appropriate, atmosphere was cosy and after party was bookie. Here’s my notes from the event.

All of the talks were live streamed and they’re available on Youtube. I was lucky to get a ticket to the event and be able to enjoy the talks live. In overall most of talks were easy to comprehend although I only had some experience with GraphQL through experiments and what I had learnt couple of months ago at React Finland 2018 conference (my notes from day 1 and day 2).

“GraphQL is an open source data query and manipulation language, and a runtime for fulfilling queries with existing data. It was developed internally by Facebook in 2012 before being publicly released in 2015. It provides a more efficient, powerful and flexible alternative to REST and ad-hoc web service architectures. It allows clients to define the structure of the data required, and exactly the same structure of the data is returned from the server, therefore preventing excessively large amounts of data from being returned. – Wikipedia“

Notes from the talks

(titles are links on Youtube to particular talk)

Adopting GraphQL in Large Codebases – Adam Miskiewicz
The event started with Adam Miskiewicz’s story from Airbnb and incrementally adopting GraphQL. It’s simple to start using GraphQL in your project but adding it incrementally and carefully in huge codebases powering large distributed systems is not quite as straightforward. The talk dived into how Airbnb is tackling this challenge, what they’ve learned so far, and how they plan to continue evolving their GraphQL infrastructure in the future. Towards GraphQL Native!

Going offline first with GraphQL — Kadi KramanKadi Kraman from Formidable Labs talked about going offline first with GraphQL. She did a nice interactive demo with React Native and Apollo 2. Users expect your mobile app to work offline and the tooling in GraphQL makes it reasonably straightforward to get your React Native app working offline. Slides

Life is hard and so is learning GraphQL — Carolyn Stransky
Life is hard, without documentation. Carolyn Stransky presented her story of ups and downs when learning GraphQL and documentation’s role in it. The problem with GraphQL is that – because there’s no “vanilla” GraphQL – there’s no central hub for all of the information and tooling necessary to learn. It’s underutilized and scattered throughout our community. The talk touched on how to better enable GraphQL docs for learning and comprehension and slides pointed to good resources.

Talks from the deep end

Some of the GraphQL Finland talks were quite deep in the content and as most of the talks were around 15 minutes, the pace was quite demanding. At the event I concentrated on topics which seemed most relevant and saved the rest for later. The sponsor’s lounge by Gofore and Digia provided nice relaxing space to get your thoughts together. Here are the topics I saved for later.

End-to-end type-safety with GraphQL — Johannes Schickling
Talk dived deep into one of the most powerful features of GraphQL – its type-system. GraphQL can be used to enable end-to-end type-safety across any language, making your application architecture more resilient and easier to evolve.

Reason and GraphQL — Nik Graf
Using Reason’s type inference you can create GraphQL servers with 100% type coverage. And Reason shines even more so on the client. Send one quick introspection request and you get full autocompletion on your schema right in the browser.