JSFoo 2018 will be held on 26 and 27 October 2018.
About the conference:
The 2018 edition is single-track event with talks in auditorium 1 at the NIMHANS Convention Centre, and Birds of Feather (BOF) sessions in the hallway. Meta Refresh – with talks on usability, user experience, design and UI engineering will be held in auditorium 2 at the NIMHANS Convention Centre.
- Security and front-end
- Backend, node.js and security
- Framework specific security concerns
- Security audits
Besides the main theme, JSFoo will cover the following topics:
- Case studies of Vue.js, GraphQL, ReasonML and other framework/language adoption.
- Architecture approaches (and case studies) for engineering web apps.
- Best practices: debugging and profiling on the web, testing, measuring performance.
- JS off the web – conversational UI, raspberry pi, IoT
We are inviting proposals:
- Full talks: 40 mins duration
- Crisp talk: 20 mins duration
- Hands-on workshops of 3 or 6 hour duration
- Birds Of Feather (BOF) sessions of 45-60 mins duration
Proposals will be filtered and shortlisted by an Editorial Panel.
Make sure to add links to videos / slide decks when submitting proposals. We will not review proposals without detailed outlines or slide decks and preview videos.
The first filter for every proposal is whether the technology or solution you are referring to is open source or not. If you are referring to a proprietary technology, consider picking up a sponsored session.
The criteria for selecting proposals, in the order of importance, are:
- Key insight or takeaway: what can you share with participants that will help them in their work and in thinking about the problem?
- Structure of the talk and flow of content: a detailed outline helps us understand the focus of the talk, and the clarity of your thought process.
- Ability to communicate succinctly, and how you engage with the audience. You must submit link to a two-minute preview video explaining what your talk is about, and what is the key takeaway for the audience.
No one submits the perfect proposal in the first instance. We therefore encourage you to:
- Submit your proposal early so that we have more time to iterate if the proposal has potential.
- Write to us on: firstname.lastname@example.org if you want to discuss an idea for your proposal, and need help / advice on how to structure it.
Our editorial team also helps potential speakers in refining their talk ideas, and rehearsing at least twice - before the main conference - to sharpen the insights presented in the talk.
Passes and honorarium for speakers:
We pay an honorarium of Rs. 3,000 to each speaker and workshop instructor at the end of their talk/workshop. Confirmed speakers and instructors also get a pass to the conference and networking dinner. We do not provide free passes for speakers’ colleagues and spouses.
Travel grants for outstation speakers:
Travel grants are available for international speakers who have led/worked on projects that have large-scale adoption. Travel grants are available for domestic speakers (without the criteria mentioned for international speakers).
We evaluate each travel grant application on its merits, giving preference to women, people of non-binary gender, and Africans. If you require a grant, request it when you submit your proposal in the field where you add your location. JSFoo is funded through ticket purchases and sponsorships; travel grant budgets vary.
JSFoo + Meta Refresh: 26 and 27 October, at the NIMHANS Convention Centre.
For tickets and sponsorships, contact email@example.com or call +91-7676332020.
The art of writing mature tests
As developers, we are all well aware of the importance of writing tests. Whether it is the safeguard against letting silly bugs slide in production code or enforcing certain styles and practices for everyone involved in contributing to the code base, we can all agree that writing tests is an important part of the development lifecycle.
But there is something else also we can all agree on.
WRITING TESTS IS A PAIN IN THE BOTTOM.
This talk was born out of the sheer frustration of:
- Writing hundreds and thousands of tests and then modifying them all because of a slight change in the code base.
- Spending more time writing tests than the actual code.
- Spending hours going through fixtures to find out where the tests are breaking.
- Mocking and stubbing and faking and what not just to create an ideal test scenario.
- Re-running pipelines and hoping the flaky tests don’t pop up again.
- Struggling with the assertion failures, stack traces and error messages to figure out what went wrong and where.
And you get the idea. We went back and forth with a lot of different test strategies and a few things finally clicked and made sense. This is an attempt to share all those learnings with developers who have faced the issues mentioned above during writing or fixing tests, in the hope that these can be used as standards moving forward to save you and your team from hours of frustration.
- What not to expect
- recommendations or comparisons b/w diff testing tools.
- preaching about writing testable js from the beginning.
- What to expect
- things you can do to improve existing tests without drastic changes.
- Why write tests?
- Not the obvious reasons.
- The developer perspective
- Current scenario
- The test monolith.
- Common mistakes and avoiding them.
- Code samples explaining the mistakes and solutions.
- Moving towards better tests.
- Minimalism and extraction is the key.
- Bringing everything together for a new testing strategy.
- Test scenario and solving it through new devised strategy.
- Better test Design