Allison Espeseth began dancing at a young age and has continued nearly uninterrupted since that time. She has been a member of Oberlin Dance Company, Kanopy Dance Company, and Li Chiao-Ping Dance Company, and has performed in works by choreographers Stanley Love, KT Nelson, Kraig "Bopi" Paterson, and Edie Thurrell. Allison received her M.S. in Consumer Behavior and Family Economics at UW-Madison and currently also provides leadership for Covering Wisconsin, a statewide organization dedicated to reducing the number of uninsured through education, outreach, and enrollment.
Lauren Gibbs is a graduate of San Diego State University where she earned her Bachelor's of Fine Arts in Dance in 2010. After graduating she moved from California to New York to further explore dance. There she performed under the direction of Kendra Portier in Dance New Amsterdam's Performance Project 2011. While in New York she also practiced with Dana Ruttenburg and Shen Wei Dance Arts. In 2012 she reclaimed her dancing roots in San Diego performing in San Diego Dance Theater's Trolley Dances under the direction of Joseph Alter. She has also practiced with companies such as Doug Varone and Dancers and Joe Goode Performance Group. Lauren is dancing for Li Chiao-Ping Dance and is in her second year of dancing for Liz Sexe Dance Company. Her experience stems from competitive gymnastics and modern, jazz, ballet and hip-hop dance. Lauren is thrilled to be a new resident of Madison!
Emily Janik graduated from The University of Wisconsin-Stevens Point, where she earned her BA in Dance and her Pilates Mat certification. She performed throughout college in UWPS's Danstage and as a member of Transcribing Dance Company, with which she attended Minnesota Fringe Festival. Her own choreography has been presented in UWSP's Afterimages and at The American College Dance Festival. Emily now creates, teaches, and performs in the Madison, Wisconsin area. She is a member of Li Chiao-Ping, and is very excited to also be dancing with Liz Sexe Dance Company. Emily has also recently performed and choreographed with Theatre LILA on their productions of The Suitcase Dreams and A Midsummer Night's Dream. Emily also teaches modern, jazz, ballet, and Pilates at various studios in the Madison area.
Ryann Marlar is so grateful to have the opportunity to perform with the Sexe Dance Company. A BFA graduate of the University of Wisconsin- Milwaukee Dance Department, Ryann had the privilege of studying under and performing for Darci Wutz, Ed Burgess, Simone Ferro, Janet LiIly and Luc Vanier. In her dance journey Ryann has performed in a variety of styles and locations: on fields of Arena football, Musical theatre in the southwest and locally in works of Daniel Gwirtzman, Ron K Brown, Laura Dean and most recently, the Sexe Dance Company.
Emily Miller trained as a competitive gymnast before turning to dance. She received her Bachelor of Science degree in Dance from the University of Wisconsin-Madison, and upon graduation she toured and performed with Li-Chiao-Ping Dance where she had the opportunity to meet Liz. Emily has roots in modern, jazz, ballet, and hip-hop dance styles. She enjoys teaching classes and directing her student performance company at KP School of Dance in Sauk City, WI, and is excited to be performing with Liz Sexe Dance!
Tim Russell lives in a world of sound. His professional career as a musician started in the Chicago suburbs playing drums in rock bands. Tim's passion for sound deepened as he attended the University of Wisconsin, graduating with a BM in percussion performance. An astute recommendation immersed him in the world of Contemporary Movement via accompanying Dance classes and composing music at the University of Wisconsin, an environment that encouraged his experimental and collaborative spirit. Tim resides in Milwaukee, where he is the Music Director for the UW-Milwaukee Dance Department. He has recently been called "the premier composer for Modern Dance in Milwaukee" (Shepherd Express), and his "compelling original music" (Madison Isthmus) has shared the stage with choreographic artists such as Li Chiao Ping, Kate Corby, Gerald Casel, Wild Space Dance, Danceworks,and Kun Yang Lin bringing Tim and his music all across the country from New York City to San Francisco.
Joe Straub is a composer, musician and sound artist from Los Angeles, California. He creates music and sound for live performance, recorded media and various combinations of both. His work includes pieces for concert performance, installation, CD, web, animation and film. He works both as a solo artist and in collaboration with many other artists and projects. He is currently based in Berlin, Germany.
His solo work is engaging, emotional and socially aware. It often plays with the boundaries between composed and improvised music, live and recorded sound, and organically and synthetically produced sound. He uses and blurs these distinctions to draw correlations to the relationships between simulation and reality, normal and absurd, beautiful and grotesque, etc.
Joe works in a highly improvisatory fashion creating a unique blend of various acoustic instruments, voice, electronic processing and synthesis. Drawing inspiration from a variety of musical forms, including contemporary classical and avant-garde, experimental noise, jazz and blues, and folk music from around the world; he creates music that is eclectic, dynamic and provocative.
In collaboration with others, Joe works on a variety of projects. He has composed music and designed sound for motion picture, performed and recorded with several music ensembles, and developed music and sound for live dance, puppetry, and other performance mediums.
He holds a BFA in music composition and performance from California Institute of the Arts in Valencia, California and an MA in music composition from Mills College in Oakland, California. He studied under professors James Tenney, Roscoe Mitchell, Fred Frith, Barry Schrader and Arthur Jarvinen.
Luigi Marino is a musician native to Rome. He holds a BA in arts and philosophy from University of Rome Tor Vergata, and an MFA in electronic music from Mills College, where he studied with Roscoe Mitchell, John Bischoff, and Chris Brown. He studied zarb with Mohssen Kasirossafar.
His recent work has focused on interactive systems able to create interactions between an extemporary performer-driven source and a computer, with particular attention to how intuitive decisions can affect a predetermined structure in a formal way.
He is the recipent of many awards such as the full teaching assistantship at the Center of Contemporary Music at Mills College, the Paul Merritt Henry Prize, and the prestigious doctoral grant from the Arts and Humanities Research Council (UK).
His music has been presented at festivals such as the ICMC, Seoul International Computer Music Festival (South Korea), Acousmatic for the People (Sweden), Intonal Festival (Sweden), Sincronie (Italy), Signal Flow (USA).
As percussionist, he is specialized in bowed metals and hand drums, with a predilection for the zarb. Improvisation has an essential role in his performances. He performed at venues such as Offene Ohren (Munich), Spazio O' (Milan), WIM (Zurich), ImprovvisaMente (Lodi), Teatro Ca' Foscari (Venice).
Jim Vogel graduated from UW-Madison's MFA program with an emphasis in Technical Direction. Both a performer and a technician, he has enjoyed being an actor, dancer, aerialist, trapeze artist, monkey on a German wheel, set designer, technical director, rigger, stage hand, production manager, stage manager, carpenter, lighting designer, lighting board operator, electrician, sound designer, sound board operator and is an all-around jack-of-all-trades. He is the Technical Director for the Madison Circus Space, and for the Sellery Hall Studio Space at UW-Madison. His latest credits are: Production Manager for "Humorology 2015" and "Humorology 2016;" Lighting Design for Liz Sexe's "–ment" and "One;" Lighting Design/Technical Direction for the Madison Circus Space's "AfterDark Circus," "Skeleton Circus" and "MishMash;" Lighting Design/Technical Direction for "Wild Rumpus Winter Circus 2016;" Set Designer for UW-Madison's production of "Wondrous Tales of Old Japan II;" Technical Director for UW-Madison's production of "Ma Rainey's Black Bottom" and "The Rocky Horror Show;" and Assistant Technical Director for Forward Theatre Company's production of "44 Plays for 44 Presidents."


Explore Savonlinna area on a tailormade tour with a local friendly guide. Recommended tour brings you to see the worlds biggest wooden church in Kerimäki and the famous Punkaharju ridge. Guide picks you up at hotel and brings back after tour. Many optional activities are available too.


text:
1:30pm Our Daily Work/ Our Daily Lives Brown Bag Series (Conferences / Seminars / Lectures)
This week's presentation titled, "Freedom from Migration and Independence as Work in Lesotho: The Dreams and Realities of Decolonization," is presented by John Aerni-Flessner, MSU Residential College in the Arts and Humanities (co-sponsored by the MSU African Studies Center).
Our Daily Work / Our Daily Lives" is a joint project that focuses on the artistic traditions of workers and on workplaces as contexts for the expression of workers culture. The richness and diversity of workers' experiences and workers culture is explored and presented through an ongoing series of exhibits, lectures, and presentations; writing and research projects; reunions; and demonstrations and discussions. The program was established in 1992 and is coordinated by the Michigan Traditional Arts Program at the MSU Museum and the Labor Education Program in the College of Social Science's School of Human Resources and Labor Relations.
Location: MSU Museum Auditorium [map]
Sponsor: MSU Museum
Contact: John Beck
beckj@msu.edu

redpajama_set_name: RedPajamaCommonCrawl


text:
<?php

namespace App\Library\ExportFile;

use App\Library\ExportFile\Export;
use Dompdf\Dompdf;

class ExportPdf extends Export
{

    public function writeFilePdf($dados, $options = [])
    {

        $template = 'index';

        $parameters['dados'] = $dados;

        if (!empty($options) and isset($options['header'])) {
            $parameters['header'] = $options['header'];
        }

        if (!empty($options) and isset($options['template'])) {
            $template = $options['template'];
        }

        $html = $this->view->getRender('pdfTemplates', $template, $parameters, function($view) use ($template) {
            return $view->setMainView('common/pdfTemplates/'. $template);
        });

        $mpdf = new \mPDF('c', 'A4-L');
        $mpdf->cacheTables = true;
        $mpdf->simpleTables = true;
        $mpdf->packTableData = true;
        $mpdf->WriteHTML($html);
        return $mpdf->Output();
    }

}

redpajama_set_name: RedPajamaGithub


I have one data set and I am looking for a function that could fit my data well. Preferably I am looking for something I can reproduce in excel and solve with solver. The function can have multiple constants, but not too many. It can also have IF-s or whatever. I am looking for the best possible fit and I am also looking for any limits (n->inf) on said function.
I tried what I could but I could not get a good fit.
In the later data set every row that is not included would have the value of the row that has the largest row number of all rows that are less than the one in question.
Can you try plotting it on a log scale? It seems like there's lots of exponential decays sort of stuck together.
I have one data set and I am looking for a function that could fit my data well. Preferably I am looking for something I can reproduce in excel and solve with solver.
You should not be asking for someone to find a best/good fit as you are. This is not arbitrary data and therefore you should at least have some idea of the form that the fitting function should have. If you don't have any idea tell us where this data comes from so we can form our own opinion on what form the fitting function should take.
Failing that a low order Padé approximation should produce a very good fit, but I would not recommend this procedure. You need some theoretical or heuristic basis for the fitting function.
Last edited by CaptainBlack; December 8th, 2014 at 08:29 PM.
This is the result of an algorithm running for 10 hours. The algorithm starts with a square polygon and randomly adds and takes away points. The new polygon is tested than to see if it is more round (more like a circle) than the previous one was. If it is better, than the new polygon is kept, if not than it will be thrown out and the old one will be used again. The horizontal lines exist because sometimes no new points are found for a while. Also these lines will keep growing longer and longer since the more the polygon is round the less likely a new point can be integrated into it.
and only go for something of higher order if the fit is inadequate.
Last edited by CaptainBlack; December 9th, 2014 at 08:11 AM.
I'v gotten a 74% fit with the later function over 80% if I change the 1 into a constant.
So where would I go from here? I tried a few things but I had little to no luck.
It seems there is a periodic element to the data that is missing from the function but I'm not sure how I could add one to the it.


Should we call it the 22-year plan?
The state Executive Council meeting in Concord last week must have provided quite a revelation for those in attendance. The presentation about the sad financial status of the long list of necessary state highway projects is a sober reminder of the cost of putting off until the future what was necessary yesterday.
Department of Transportation Commissioner Charles O�Leary had the unwelcome task of telling a truth that�s been nearing boiling point for a few months. O�Leary said cutting only $1 billion in projects from a 10-year highway plan would add 12 years to the not-so-master plan.
For those keeping score at home, O�Leary has cut $1 billion from a $4.1 billion plan. That�s around one-quarter of the funds in a state with a wide range of needs in every conceivable transportation sector.
Waiting on a mythical silver bullet of greater federal highway funds does not address what we could do for our state.
It�s obvious there is a severe revenue problem in New Hampshire, and the one equally obvious solution is taking a serious look at the gas tax (unchanged since 1992) and turnpike toll fees (unchanged since 1989) to help pay for traveling on our crowded roads and highways and crossing aging bridges. No one wants to raise taxes or tolls, but for too long we�ve tried to get by on the cheap by not paying realistic prices for necessary infrastructure.
Furthermore, it approaches a dereliction of duty on behalf of state officials to improperly match infrastructure investment to a period of economic and population growth unrivaled in New Hampshire�s modern history. It�s been an issue of accountability duck-and-cover over the years, as politicians of both parties failed to do the right thing. They kept passing the buck from one budget cycle to the next.
But the same can be said for those who have lived here for 50 years or five. It is our collective responsibility to invest in our communities. It�s the collective us who empower our politicians with cries over taxes and for a laundry list of other expenditures that stray too far from infrastructure investment.
It is the people who gladly accepted a toll discount first on tokens and today on the EZ-Pass system. Why are we paying less than those using cash for the privilege of ease and convenience?
This isn�t a tax-and-spend issue that can be solely pinned on our governors and legislators. It�s not a political football of the rhetorical damage raising the gas tax by a nickel or dime a gallon would cause the economy and families.
This is a tax-and-investment necessity that could have a major negative impact if ignored any longer. It�s already having that impact. Ask anyone who has sat in traffic approaching the Hampton Harbor bridge or in the growing gridlock of Route 33 that connects Exeter, Stratham, Newmarket and beyond to the commercial hub of Portsmouth. Ask anyone who has crossed the decrepit, neglected Memorial Bridge in Portsmouth.
Like it or not, Granite Staters, it�s time to pay a long overdue toll.


GREENE TWP. � The Rochester High School football team did pretty much whatever it wanted against South Side Saturday afternoon.
Quarterback Jasson Adamson threw for 175 yards and two touchdowns. Trey Johnson scored four times. Terry Gettings caught a 67-yard touchdown pass.
Until the start fourth quarter, when a gang of players in freshly laundered uniforms trotted onto the field, Rochester was stopped on only one possession; the Rams took a knee on the final play of the first half.
Rochester�s 45-6 dismantling of South Side clinched the outright Big Seven Conference title, and the display was nothing short of impressive to anyone who witnessed it. Anyone, that is, except the folks in blue and white.
�We�re still waiting to have our best performance,� Johnson said.
Rochester might be perfect in the win-loss column (8-0 overall, 6-0 Big Seven), but no one in the Rams� locker room is satisfied yet.
�We haven�t played our �A� game yet,� coach Gene Matsook said. �I think we�ve probably played a B-minus game at the most at our best. People aren�t going to believe that, but us inside, we know.
Adamson was close to perfect Saturday. He completed his first eight passes, with three of the final five going for touchdowns.
His first touchdown was on a quick pass over the middle to Johnson. The ball was thrown on a line slightly behind Johnson, who reached back, snared the ball with one hand, then spun to face nothing but open ground.
That score answered the only one South Side (5-3, 3-3) managed for the day: an 86-yard bomb from Josh Martz to Kevin Gergen. Gergen�s catch and run cut the score to 12-6, but that was it for the hosts.
Adamson�s other two touchdown passes were on perfectly thrown balls: one to tight end Gettings over the middle and one to receiver Troy Belcastro for an 18-yard score. His only misfire was on his final attempt when he overshot an open receiver.
That�s the battle cry Rochester will rally around for the rest of the season.
ROCHESTER (240): T. Johnson 8-67, Gallagher 8-53, Tapia 4-44, Adamson 6-25, Goettman 3-19, Glass 4-15, Bell 4-14, Ratti 1-5, Richko 2-minus 2. SOUTH SIDE (65): Shaffer 11-35, Price 2-11, Checkan 3-8, BonAnno 2-6, Potts 3-4, Beal 1-1.
ROCHESTER: Adamson 8-9 for 193, T. Johnson 0-1, Richko 1-2 for 13. SOUTH SIDE: Martz 5-10 for 123, Price 0-0.
ROCHESTER: Gettings 2-102, Johnson 2-50, Belcastro 1-18, Blackwell 1-13, Gallagher 1-12, Slade 2-11. SOUTH SIDE: Gergen 4-123, Checkan 1-0.


(ML013) Learn how to add fill licks to a 2 chord jam (A and F# Minor). I'll show you the scales used so that you can improvise in this style. This lesson also comes with a bonus video explaining what a "Relative Minor" chord is.
This is some more of just what I'm looking for Brian! I may try to add a few more chords and see if I can come up with another song!
I find it better also getting into the F# major by using the open high e string in the first riff. Gives you more time to set up of the F#maj.
Another fantastic bite size lesson, you truly are such a blessing to the guitar world, thanks again Brian.
Enjoyed this lesson a great deal. I put it in a loop and created some new leads.
style blues lessons have been especially interesting and , with practice, I have nailed a number of picking patterns.
Thanks for your great lessons and congrats. on your 200th one.
Look forward to them every week Cheers Trevor.
is that a cello in the background?
Brian I love these micro lessons. Especially this one I am really starting to understand the guitar. Thank you my friend.
What is the 2nd position F#m you show at the end of the extended lesson? What open chord is that based on? It looks like a C or F but neither make sense to me.
Aaron, I was playing lots of chords at the end of the extended video. I don't know what you're referring to?
Great lesson for improvisation.Firstly I identified all the A majors and F# minor chords I knew on the fretboard which is a good takeoff point for finding riffs in different positions. and the notes that work with each chord. To create a break or chorus I used D6 triad or D with E6 and E because they work well with A major. So can I use chords that work with F# minor as well like B and C#? I guess I should see if these work in a progression with A and F#minor.


Writing a book review the most demanding projects a pupil may have. As soon as the assignment therefore the due date get, there was scarcely a real means around it. Those who are merely hidden along with other more urgent tasks have only 1 alternative. That is to employ book review writing solution to have the task done. Later on, we are going to make an effort to elaborate the most effective faculties of this top services that may do that for your needs. This way you end up having an A+ book review that you'll be pleased with.
The greatest people ask when you need the guide review to be achieved if there are numerous certain guidelines that they should know about. Composing guide review is pretty easy while the format is well familiar for their writers. Nonetheless, some teachers prefer to spice up things from time to time with the addition of something different to your task. In those full cases, you will need to notify the authors that may do the writing in your behalf about this.
This is certainly something you can very quickly always check through their recruitment page that is usually available at the base of their site. Read the section to help you look at requirements that are minimum an author to do business with them. The greatest ones employ only native writers by having an background that is academic past experience as article writers.
For the business like this to work well, it must work such as a well-oiled machine on every level. The writers, and all the way to the people that work in customer support, everyone needs to follow specific custom writing service standards from the people that maintain the website.
The consumer help could be the one which directly represents the business and the ones that may make or destroy the feeling. The most effective ones have actually highly trained customer care that do not only is courteous it is competent about every service they feature. Also, they are able to constantly look to your situation and offer an improvement or solution any relevant concern over it.
This is certainly a necessity for every single respectable business in this type of work. They are paid by you for top level work that is 100% initial, and there is no compromise here. The most effective people are so confident within their authors which have no nagging issue guaranteeing that.
Again, this too boils down towards the quality of these writers and exactly how adept these are typically. Most times their writers that are professional the work done without the need for a revision. But sometimes if detail is missed, or there are many instructions that are special you forgot to say before, there is always an area for correction.
They provide other writing solutions such as for example editing, proofreading, essay writing, etc.
All this work is much more than enough to assist you together with your selection. Adhere to it, and there's no path to take wrong.


HeartShaper® Children's Curriculum is designed to help children in your Sunday school or activity club discover God through His Word. Each session will take your group through the Bible and its key themes, encouraging a life-long love of Scripture and helping children to see how God can shape their lives.
This Primary age edition, aimed at ages 5 to 11 has fifty-two sessions for your Sunday school or children's activity groups with guided leader's notes and reproducible activity pages.
These are complemented with reproducible activity pages, including special needs friendly resources to ensure every child is included and made to feel welcome.


When I was a kid, I read the New Yorker every week, and it formed my ideas about what being a grown-up would be like. I particularly liked a Talk of the Town feature, which usually began, "We have heard from our friend, the long-winded lady." "The long-winded lady" (who I later found out was Maeve Brennan) would write her wry observations as she sat alone in a bar or restaurant, having a cocktail, watching and listening, noting the ironies, peculiarities and peccadillos of the people she observed around her. It seemed to me at the time that having a cocktail and eating alone in a restaurant was the epitome of being a grown-up, and I could hardly wait to do it. I was probably seventeen the first time I tried it. I quickly found out a few things. One, it wasn't any fun without the drink; and second, that a young woman by herself in a bar or restaurant is like an itch that must be scratched for a good number of men. I was rarely left alone to observe the peccadilloes of the people around me; instead, I was drawn into conversations with men who were trying to pick me up.
I didn't want to be picked up. I wanted to be alone.
Maybe it was the incipient writer in me, but what drew me to the long-winded lady was the idea of a woman alone in bars, restaurants, hotel lobbies, streets, observing and eavesdropping. She was not interviewing; neither was she the impersonal omniscient narrator. She was a woman unapologetically alone.
You don't often see women alone and okay in fiction.
A solitary man is often seen as heroic. The brooding moody loner, wounded and complex, a flawed man who doesn't fit in or really belong, can still be, as Raymond Chandler puts it, "the best man in his world." Women are drawn to him, only to be left by him. He has bigger fish to fry than forming bonds.
So what's a girl to do, when this is the romantic ideal that calls to her, too? Not being the expendable one, who makes trouble, falls for the hero, and gets left behind, but if she herself is brooding, troubled, tough and smart, with a sense of justice, a troubled past, a need for redemption, a defining quest that doesn't involve getting or not getting the guy?
Why are lonely men romantic, and lonely women pathetic?
Maybe, along with equal pay and reproductive freedom of choice, women should claim equal access to a heroic ideal. In addition to the male privilege of not having to worry about what to wear and being distinguished rather than discredited by signs of age, perhaps women can appropriate the appeal of the outcast, the misfit. Marginalized by her inability to fit into prescribed roles, yet still being the center of moral good.
The problem is, of course, that the archetype of the loner hero is a byproduct of patriarchy. It requires leaving the world of women behind. Women can be cherished or demonized, idealized or eroticized, but not lived with. Children and family, connection and care are valued primarily as spurs that goad a man onwards and away, to protect and defend a world in which he can never truly fit in. It is a paradigm of separation and disconnection.
This chivalrous ideal, of defending home and hearth by leaving it behind, doesn't translate so well when the leaver is a female. Patriarchy succeeds by relegating all the needs for bonding, connection and care to women, and it's not part of the deal for women to reject or fail to fulfill them. The women who have needs and wants that have nothing to do with making homes or keeping them running, well, we're the bad girls.
We don't quite fit in either.
One of the reasons (there were many) that it was so difficult to finish my first novel, Coldwater, was that I was aware that in Brett Tanager, I was creating a hero, not a heroine. Someone whose need for redemption drives the story, a woman whose quest has nothing whatever to do with whether or not she hooks up with some guy.
I spent so much of my life knowing that I was not like other girls, but hoping no one would find out. So I wrote a book about a character who also was not like other girls, and then was afraid of what it would reveal about me. The response from readers has been gratifying beyond anything I could express.
Turns out there are a lot of us. Women with strong feelings and deep longings, problems to solve, obstacles to deal with, goals to attain and journeys to take. Quests that might include altar and bed, but not hold them out as the ultimate goal.
Women who can eat alone in restaurants, not looking to get picked up.


Described as one of the worst maritime accidents in recent Queensland history, an inquest into the deaths of six men who died in a fishing trawler accident off the coast will examine how the tragedy unfolded and whether search and rescuers could have done better.
The trawler Dianne sank in rough seas off the coast of the Town of 1770 in October 2017 and only one of the seven men on board survived.
Beginning tomorrow, coroner David O'Connell will examine how they died, what caused the trawler to sink, the safety measures on board the vessel, and if the search and rescue operation was carried out appropriately.
The bodies of four of the men who died have never been found.
Skipper Ben Leahy and Adam Hoffman were recovered from the sunken vessel almost a week after the recovery mission begun, while crewmen Adam Bidner, Zachary Feeney, Chris Sammut and Eli Tonks remain missing.
Ruben McDornan was the only person rescued after he clung to the overturned hull for several hours.
A sailor found him wearing only a pair of a shorts, about 20 nautical miles from where the boat was thought to have gone down.
Mr McDornan has spoken of the night the Dianne sank and the moment he realised his six "brothers" were going to die.
"I thought I was going to die. I was like, this is it, we're not getting out," Mr McDornan told Nine's 60 Minutes last year.
Mr McDornan fought back tears as he recalled his night at sea and reflected on the efforts of his fellow crewmen to make it out alive.
"I could hear some banging, and I just banged, and then instantly I heard banging back," he said.
"I wanted to go back under, but the boat was completely submerged.
"I just broke down, the whole thing of … I've lost my mates, my brothers."
The family of the men who did not survive have called for safety reforms in the industry and signalling technology to be mandated.
modifying external doors to allow them to open against outside water pressure, e.g. sliding doors.
The trawler was recovered and taken to the Port of Bundaberg in February 2018.
The inquest is expected to finish on Friday.


text:
InfoQ Homepage Presentations TypeScript for Enterprise Developers
The next QCon is in San Francisco, November 11-15, 2019.
TypeScript for Enterprise Developers
Jessica Kerr talks about some of the great things in TypeScript, like the flexible type systems and the possibility to test before compilation, but also things that make TypeScript painful. She shows how Node and npm work differently from the JVM (or CLR), and some of the surprises she hit learning this language.
Jessica Kerr develops development automation at Atomist. After a dozen years in Java, she branched out to Scala and Clojure and Ruby and Elm and more. Nowadays she works in TypeScript, on tools to help developers automate more of our own work.
Software is changing the world. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
This talk is about TypeScript for the Enterprise. In particular, it's about TypeScript for Java, C Sharp, Scala developers. It's about TypeScript on the server, so running on node. If you're a front-end developer, half of this talk will apply to you. If you're a JavaScript Node developer, half of this talk will apply to you. If you are a Java, C Sharp, or, like me, Scala developer, I think you'll get a ton out of this talk and hopefully you won't fear Node quite as much as I should have.
Today what I want to give you is five awesome things about TypeScript. This is not even close to comprehensive. These are not the most awesome things about TypeScript, they're just five of my personal favorites. And then I'm going to tell you five things that tripped me up and hopefully will not trip you up, because you'll expect it until you won't be as angry as I was. This will be fine.
But first, what is TypeScript anyway? So TypeScript is a language, but really it's a compiler, the compiler's executable as TSC. The TypeScript language is a strict superset of JavaScript. You can run your JavaScript files through the TypeScript compiler, or you can rename them to .TS, and they're officially TypeScript and you can run into the TypeScript compiler. So basically the compiler is a function from JavaScript, plus optionally some types as many as you want to JavaScript, again, more JavaScript, different JavaScript, and some type errors. You get to choose how many type errors, also some type definitions, we'll see that soon.
Five Awesome Things about TypeScript
But the interesting part to me is how you get to decide how many type errors you want out of the compiler at the given time. That is my number one favorite thing about TypeScript, the gradual typing. So let me show you how that works. Here I have a Node project, so I've run npm init and I've got a package.json. But I have one empty TypeScript file, but I haven't set this up for TypeScript yet. The first thing you do when you want to run TypeScripts is having installed TypeScript, I run tsc --init. And that creates for me a tsconfig.json file, there it is. See, the thing about the TypeScript compiler is it's very flexible. There are so many compiler options you would never pass them all in on the command line, like you might do with Java C. With TypeScript, you get this whole file, and these aren't all of them, but these are most of them. It's Json plus comments, which is nice of them, because you need them with that many options.
The first ones of interest are the Strict Type-Checking Options. Step one, when I start up TypeScripts, is change strict to flase, step two is change it to false. I'm pretty consistent in that really. So strict to false. And now it's just going to be fine if I give it a JavaScript, it'll be good with that. I'm going to write some JavaScript in this file. Here is a function, printStatus, it takes one parameter which is status and it just does a console.log, that's JavaScript for System.out.println.
Now I'm going to cheat, and this is TypeScript, this interpolated string, that's okay. Then I'll call the function, printStatus running, yes, okay. Then I can test this, I can run ts-node status.ts, which is going to compile it and run it at the same time. Status is running. Can people see this? Is that big enough? So good thing there are 18 screens in this room. But also if I've got the compiler running in the background then I will get a JavaScript file, and I can Node status.js. Let's go look at that JavaScript file. Status.js, it looks just like the TypeScript except that the interpolated string is replaced by string concatenation.
One beauty of the TypeScript compiler is it outputs readable JavaScript. It aims for your JavaScript to look like if you have written JavaScript. JavaScript, let's face it, it's the bytecode of the web currently. Until WebAssembly is sufficiently implemented that we can start targeting that is bytecode, JavaScript is bytecode because it runs in the most universally available runtime, the browser. There are lots of levels of that. Sometimes you want your JavaScript to be tiny if you're shipping it to the front-end, but when you're running it on node, we don't have that problem. We have lots of space on the file system. So TypeScript totally aims for the most readable JavaScript possible, which makes me very happy.
Well, this is pretty identical now because I don't have any types in it, but I want to see what types it inferred. So I'm like, "TypeScript, tell me about your types." This is the next thing I change into tsconfig, I want it to output the declaration files. If you're publishing a library, you absolutely must do this. If it's just an executable, you could get by without it, but it's useful anyway. When I tell it to produce declaration, and notice that I could also ask for source map and more mappy things then I get, oh come on do it, TypeScript, I get a status.d.ts.
This is the types, there's no code in this file, they're only types. The other file has all the code. JavaScript has all the code, the d.ts has all the types, so I can see that it inferred that my parameter has a type of any and my function returns void. So any is the default type in TypeScript, it means - I don't know, it means I have no idea what this is, this is something out of JavaScript plan, I'm going to let you call anything on this thing, and I'm going to let you put anything in it. It's your job. Any is like stepping outside of the type system and you can do that at any time in TypeScript, which is awesome. But I don't want to do it often.
In TypeScript there are kind of like two spaces that the compiler thinks about your code. One is the runtime land, also called object space, and it uses that to produce the JavaScript, this is all the stuff that's available at runtime. And the other space is type land where it's thinking about the types. And it keeps those two things separate and outputs them differently.
Now let's make it pickier. Let's get some meaningful types in here. The first thing I don't like is that my parameter- I didn't even bother to declare or type on it, oh that's so unsafe. I'll go to my tsconfig.json. Before I fix it, I want to make the compiler hate me. Because that way it will stay fixed, and everyone else who starts adding code to this will have to type their parameters, too. This strict option is basically like it's taking all of these six and putting them together. If you set strict true, you get all of these. But if you set strict to false, and you get to pick and choose. So now I'm choosing to set no implicit any to true, and that's going to get me a type error here, and it's going to be angry. Parameter status implicitly has any type. Great, it's yelling at me. This is super easy to fix.
Now it explicitly has an any type and the compiler is happy. Nothing has changed in the types and nothing has changed in the Json, but I'm being explicit, that's nice at me. Next, I want to enforce that I don't use any as a type. Now this gets into one of the really cool things about gradual typing in TypeScript, is it's not all in the compile step. The type errors, you can divide them between the typing step and the linting step because the compiler is also a library and tslint uses the compiler as a library. So tslint is drastically more powerful than jslint because it has both that runtime space and that type land information to use to think about and do static analysis on your code.
So I need to bring in tslint for this one. So tslint --init and, of course, I get another JSON file, tslint.jason in which it tells me, it's going to start with the recommended rules. What are the recommended rules? Good question. I had a hard time finding them. I actually had to look at the library code in order to find the recommended rules, which is a pain, but that's okay. We'll find them as we go along. Well, we'll learn them as we go. Let me make sure I have some sort of error in here.
Let's run tslint. To do things right flags for tslint are -- project. Which says, "Look here for my tsconfig file and actually use the ts compiler for your analysis". And then format verbose, tell me which rule I just broke. It tells me no console, calls to console.log are not allowed. Come on, care about something else! No, that's all it cares about. Actually that's not the error I was looking for, because I totally want console.log in this program. I mean, it's a silly little tiny demo program, but it wants to console.log.
Now, the awesome thing about tslint, when I put my errors in the linting phase, I get to scope them. Because I can turn off tslint. By default it's going to work everywhere. But I can say tslint:disable, in this case, I'll do next line. I can disable linting at the file level, at part of the file, at the individual line. I can disable linting in general or I can be specific about which rules I want to disable. Am I modifying the JavaScript? That's my problem. There I go again, online JavaScript. Let's put that in a TypeScript. And then I'm going to show you that I can get some errors there.
Now it shouldn't care about console and is going to care about, "Oh my god, there is a missing semicolon. Oh my god, you didn't end the file with a newline which just drives me bonko," except you can say -- fix and then it can add the semicolon so they can add the newline and not bother me, and then we're okay. And now it's all happy, that's good, because we got the comment in for the console.log. I'll warn you, there are some linting with auto fixes that will semantically change the meaning of your code, thank you JavaScript and truthiness. But watch out for those, disable them when you find them.
In the meantime, I am happy that I've disabled no console, and I love that I can scope with this. For instance, I'm going to make it invalid for it to say to type with any explicitly. But now, once in a while, I really do want to use the any type, I want to step outside type safety. I'll be able to override that because it's a lint rule, not the compiler rule, and the lint rules are skippable. The other way to change this, because that comment annoys me, is to go to tslint.json and override the recommended rules. We can say no console, conveniently VS Code here is giving me autocomplete, so I don't care about no console, but I do care about no any. So I'm going to add no any true, and then it's going to be happy here but it's going to give me an error when I run the linter. Come here, run the linter. And it's going to say, "Yes, type declaration of any loses type safety."
Now I can change that. Now, it's going to tell me that and I can make it a string. And everyone is happy. The linter is happy, the compiler is happy. My declaration change to say it's a string, and we're good. Now notice that I can't pass nothing here. The compiler tells me expected one arguments got zero, but I can't pass undefined. Then if I run that ts-node status.ts, it's going to say status is undefined and that's kind of sad. If I want to enforce that you can't just pass undefined or no for absolutely anything, then I'll comment out this strictNullChecks and turn that on, and now there's anger here.
Undefined is no longer a string, I can tighten that. Now, if I do want to accept undefined, I can do that two ways. I can say string or undefined, in which case, I'm allowed to pass undefined, but I'm not allowed to pass nothing. Or I can say status is optional, and then I can pass undefined, I can pass nothing, it's an optional parameter. But right now I don't want it to be optional, I want it to be running. Now I want to tighten my type safety some more. I'll show you the number two of my favorite features of TypeScript, this one is really weird.
I can say, you can't just pass any string, you have to pass literally running. Literal strings are types, they exist in type space as a specific thing. Why? Why would you do that? Well, historical reasons, of course, like everything, TypeScript not only does it have to support all of JavaScript since the beginning of time, it has to support typing the major JavaScript libraries, which is saying something. We have to be able to put useful types on GQuery.
Or, for another example, let's look at a node. One of the built-in modules in Node is child process, and child process, it's what you use to fork, to spawn off another process in the operating system. It gives you back a thing that has this on method on it, and that on method takes as its first argument the name of an event that you're going to trigger on, and its second argument of function to respond to that event. Well, depending on which event, which is a literal string that you pass in, you need to pass a different type of function. If you want to trigger on close then you need to pass a function that takes a number and a string. But if you trigger on disconnect, you better not take any arguments at all because you're not getting any.
One of the most important things about typing for me is when I'm passing functions around. If you're going to do functional programming, you want to know that your functions fit together, that is incredibly hard to debug, hello closure. I really appreciate typing of functions in particular. But in order to distinguish that they had to give me this information so I can use this library correctly. They had to make the literal string a type so that you can overload the method declaration. You can't overload methods, because that's not a thing in JavaScript at runtime. Your types can never affect runtime because they don't exist there. But you can overload the declarations to make sure people get the types right. So that's what they've done here, and it's wonderful and it has the result of literal strings being a type.
Now, it'll catch typos for me. I can't pass running space in here anymore, but that's not super useful if I always pass the same thing. But how about if I can pass running or stopped? Now that starts to make sense, my function is really saying what's meaningful to it. Now, yes, TypeScript has enums. Yes, I should use them here. But I love this because it's cute. It's a great place to start too. As I'm prototyping stuff, I'm just going to set a string in there. I'm not going to go make a separate enum class, blah, blah. I'll come back and make an enum class, that's fine.
In the meantime, let's do something a little more interesting with that. Let's start by making this a type alias. So type status, we'll give it a name, it's running or stopped. Then let's make these richer. Instead of string types, let's use literal object types. We'll have a kind of status, the kind it might be running, and if it's running, we might know where it's running, so like a host name. Or if it's stopped then we'll give it a kind of stopped. And maybe we have since when was it stopped, that could be a time stamp, we'll call it a number.
Now we have a more meaningful or, it's either a running status or it's a stop status. But then we want to do something with this, now we're going to want to print status.kind, and where we're running, status.where. But that's angry, because TypeScript knows, it knows this is a status, but it might be a stopped status, and that is not going to have the where. So these union types, these or things is totally number three, one of my favorite things about TypeScript. But they're not terribly useful if you can't access those extra fields that it might have, but watch this.
First we'll make this, so this is going to be a kind of running. Come on, make this compile, kind of running where QCon. So this should work, in fact, if I just run it with node, it probably will work. Status is running at QCon. Notice that the compiler compiled it, it's still got type errors, it's angry at us wherever you're on the right, but it compiled it anyway. Because runtime space and type space are so different that their compiler will happily spit out JavaScript even though it has type error. So it can give you the JavaScript and the type errors at the same time. Amazing, it won't output the type definitions, I don't think, when it has compilers.
I really only want it to print out the where if the status is running, and I need to check status.kind here, there we go. So if status.kind is running, and look at that, now it's happy. It knows that if in that condition of my if statement, if I have checked this and that the kind is running, that it definitely has a where, it can deduce that. This is number four, and this is super awesome. Type narrowing within blocks of code. It knows there's a when there, and if it's stopped since when, it's not going to accept that just generally. But if I stick it in an else, then it can do as well. I see that the kind was not running so it must be stopped, and if it stopped then I have a when. The compiler is super, super smart about narrowing these types. And that's fantastic, that actually makes it useful. Now I can ts-node the thing because it compiles, and it's still running at QCon, that's good.
Check this out, if I make status optional, no, you can't even check the kind, because it might be undefined. No, no, no, no. We have strict no checking turned on. But if status is undefined, return, and suddenly it's like "Oh, okay, I see that you're going to return if it's undefined, so that's fine." The rest of the function, it's definitely defined. So that's super amazing. I love that.
Now this, though, it kind of requires a little knowledge into this type thing. What if I'm an OO Developer, in Java and C Sharp and I like to write classes, then I would probably make an interface here. We're going to have a kind of running or stopped. And that's the only common field, so we'll just declare that, and then maybe we'll have a class running status. I do find that TypeScript is immensely more comfortable than JavaScript, especially JavaScript back when I tried to use JavaScript, which was a little while ago. Being able to type things, being able to make classes and interfaces so nice.
I can say we have a kind of running and I can make a constructor. We're going to have a public field, it's read only and its name is where and it's a string anti-constructor body. You can use classes and interfaces instead of type aliases, which is very comfortable. Now, we'll have a new running status of QCon and it'll work in the JavaScript, but TypeScript is angry again, because now status.kind equals running is not enough to say that there's a where field. There could be other implementations of the interface that also have a kind of running.
I have to get more specific in my condition. I can say if status instance of, there it is, RunningStatus, and then it works. I'm not going to make that compiles, so I'm just going to delete that. Then it works, and that's okay except, I do not like exposing concrete classes outside of my conceptual library. Pretend the printStatus is in its own file and shouldn't have to know about the concrete instance of RunningStatus.
What I really want to say is, if this is a RunningStatus then I should have access to where. So here is another really cool thing. In the place where I do know about the implementation of the class, I can define a function is RunningStatus, it takes any status and the return type is really, really weird. Status is RunningStatus, it's super weird. By the way, I'm going to put this comment in here. This is a type guard, that's what it's called, you're going to need that phrase in order to google it every time you use it, because I always forget the syntax. But it needs to return a Boolean about whether status is RunningStatus.
Here I happen to know I can do the instance of, or I happen to know that I'm pretty sure it's going to be RunningStatus that has a kind of running, because I know the implementation at this level. Now it works. You can write custom functions to guide the type system in its narrowing of the types within the block. I love that. I mean it's a little bit of boilerplate, but it works out because then in the JavaScript, that function is doing a real runtime check, because the type information is gone at runtime.
Cool, I can do that. But what if there is another thing here. I'm still exposing the concrete implementation here. There's another thing I could do. I could say, "If it's RunningStatus then its status and it has aware field that is a string." Oops, where is my ampersand? This which looks really weird and is not formatting very nicely. This is type intersection. So just like you can or types, you can and types. TypeScript happily puts them together, because this is all duck typing with one exception that I'll probably rant about later. This all duck typing, so we can just combine types and you can subtract types, and you can run functions over the keys in this type. And you can do really weird things, but I am not going to talk about that today, because I don't think you'll ever use it.
But if you love Scala, and you love to make impossible things not compile, TypeScript is fantastic. If you love using those libraries without actually doing the dance to prove to the compiler that it's going to compile, then you'll love TypeScript. It's a win, you get both. That's number four of what I like, is the type narrowing, fabulous.
Number five. We have to broaden, we have to get into the ecosystem as a whole, because we don't program in languages, we program in language systems including the dependency manager, including the build systems, including the linters, including the runtimes. The syntax of language is a piece of the surface, and JavaScript is a very rich ecosystem. It's very nuanced and deep, and there's a lot of stuff in it, which is one reason to use it. But it's also one reason that it's challenging, especially when I came at this from Java and having been in Java for a dozen years, so not remembering how painful it was to learn this stuff. I was like what even is going on here?
I had to learn some history of JavaScript for this to make sense. And it turned out there are so many JavaScripts. On this timeline here I've charted only the specs. ECMAScript is the spec, which various JavaScripts implement some of, and various portions of. Even then you've got every browser implements, what the heck it does, and it's just super subtle. TypeScript wants to support all of this. But the result of all these varying definitions of JavaScript means that you almost never write JavaScript in the same version that you want to run. Because if you're a front-end developer- can you tell I'm not a front-end developer? Because I don't know all these built tools and stuff, but I know I've heard of them and I'm trying to avoid them for as long as I can.
It's a little simpler on the backend, because you write in one version, some modern version of JavaScript that you select. And then you run it through Babel or whatever to get the older version of JavaScript that will run on all of the browsers that you're targeting. It's easier on the server, fortunately, and it's easier with TypeScript, because I don't need to run in all the browsers. I need to run in whatever version of Node I'm running. Or if it's a library, whatever version of Node I want to acquire the library's users to run.
I can choose which version of the standard I'm going to target. And I don't need any of this stuff. I'll just use TypeScript compiler. And tslint, I want tslint in there. I don't have to choose a version of ECMAScript, I get with TypeScript something more advanced than the latest version of ECMAScript. TypeScript keeps up with ECMAScript, it's implementing all the new things as soon as they're pretty solid, that they're going to be in the standard, TypeScript is right there. So you get to be way ahead and also choose your runtime JavaScript. That's one of my favorite things, and it's also my number one least favorite thing. I mean, a thing that tripped me up.
Five Things That Tripped Me up about TypeScript
If we look at tsconfig, the first object option up here and basic options is target. Now I know what that means. It means the JavaScript that I expect to execute on whatever runtime, I'm going to run it in. And it's set to es5. You may have noticed but probably not because I moved this pretty fast, that in our JavaScript output we don't have a proper class. We have something that's commented as the class, but it's actually a function, whereas modern JavaScript does have classes and the reason for that is we're set to es5 as a target, which is pretty old. If I set that to something current like es2017, then I have a class.
TypeScript is going to make the most readable JavaScript it can for the target you've selected. This is a good idea, but it's also confusing. It gets a lot more entertaining when you switch it, when you have an async function. If I make this function async, this is another of my favorite things but it didn't make the list, then I'm still targeting es2017, so it's going to be fine. It's going to be like, async function, no problem, I got that. But if I set this back to es5, where is the JavaScript? Actually this is TypeScript being very kind, defining some constants that you don't have to read in order that your code be as readable as possible, because the printStatus function looks a lot like my printStatus function. You also get source maps, but in the meantime, the JavaScript actually looks like it. Now, your stack trace is not going to be pretty.
So that's why you should target the most advanced version of JavaScript that you can get away with for the version of Node that you're going to run, and that's super helpful. But there's another problem with this, so let's get into evil thing number two, and hopefully you won't be surprised by this.
PrintStatus is angry. It's angry because it requires the promise constructor. Why? If we go look at the type declarations, because I made it async, it's returning a promise of void. Let's just declare that explicitly, so that it will be angry over here for me. It's angry because it doesn't have the promise constructor because that's not in es5, the standard. But I can get more explicit, because runtimes don't just implement one version of the spec or another, that would be too easy.
TypeScript lets you get more specific and it's got this lib thing. First of all, lib, entirely type space. There is nothing runtime about this. You want your lib - whatever they call it, they call it lib - you want your lib declaration things to match what's available in your runtime, unless you're importing libraries that require stuff, and then you want them to match whatever makes your libraries compile. I just start adding stuff until it gets happy, and then hope I don't hit that in runtime. But I have yet to have a problem with it so this is probably fine.
Anyway, it wants the promise bit so I can tell it, yes. In node, the version of Node that I'm running, which is true, I am going to have the es2015.promise. So then the promise can get happy except, look at this, look at this garbage. TSC - oh no, what's a number? What's an object? I can't find an array. It took me till a couple days ago. I finally figured out what's happening here. What's happening here is that when I override, where did my tsconfig go, when I override the lib at all, it takes away the default. And the default was es5. Because I'm targeting es5, you'd think that would be available. Well, if you add anything to the lib then you have to say, "Oh, yes, and the obvious thing." Now it's going to be happy and it's going to compile, and it'll be okay and it will target es5.
I forgot to tell you how you know which ECMAScript to use. There is a wonderful website called node.green, whatever, it's great. It's two words, node.green. Up here it says es2015 support and across here you have the various versions of node, and how well they support es2015, nobody does, whatever. If you want to know what Node or whether you can use es2017, you scroll, there's a lot in es2015. Okay, we made it to es2017, and it's telling us that as long as you're running Node 9, it's 100% complete, you're fine. If you want 2018, scroll until this says 2018 up here, then you need to be a Node 10.
So that's how you know, and this is divided up into all those like different feature things. As you get more granular with your lib, you can check. But it only matters if you actually hit that code at runtime anyway. Just finally in TypeScript 3.1, they've made a way for libraries to declare which of these things they need, which is totally helpful because I'm tired of guessing. That is totally number two. You have to like specify your lib sometimes.
Number three is right in between. Give me your tsconfig. Oh, there is. You also get to specify what module system you're using. What? I mean, coming from Java that makes no sense. I use packages, I put them on Maven, but no. JavaScript, way back, of course, this is a historical reason, didn't have a modular system at all. Everything is in the global space. You want privacy? The only way to get privacy is within a function. So people start making functions and then immediately calling them which confuses everyone who was not them or a JavaScript developer, but that's okay. Then people come along and they're like, "If we standardize the way we do these functions that we immediately call, then we can share them." So they start inventing module systems, plural.
If we go back here, I mean es6 actually includes es6 modules as the spec, which Node doesn't even implement, except in experimental mode. That would be too easy, but meanwhile, before that, there's all these others. Someone made CommonJS, which is consistent with required.js. But this is for this server, I think it's so confusing. Then there's module system AMD, which is optimized for the front-end where you actually care about how many bytes you're shipping over the wire, which is not a concern on the server. And then there are some other ones that, fortunately, if you're on the server, you're on node, you pick CommonJS, you're done. But you can output more, and TypeScript, will happily make your code compatible with as many modules systems as you choose. But that totally confuses me.
Also, another thing to know about modules. Now a module is a file, is a module, is a file, except when the file is a script, and ours is a script. How do you know it's a script? Well, it doesn't participate in the module system. It doesn't export anything and it doesn't import anything. And that means when the JavaScript is out, it's just out. It's just doing its thing, it didn't put anything weird. Well, okay, sorry, async maybe should make that not async, then things would get prettier. But it's just JavaScript. If you no longer promise, bam. Oh, no, it hates me, quick undo. We're just there.
Now, it's not a module, it's just a script. But, if I choose to participate in the module system by exporting or importing - so let's export the printStatus function - then my JavaScript looks different. I got this use strict thing, we got this defineProperty. I don't really know what that is. There are some exports down here. But because I'm using TypeScript, TypeScript knows what that is, it knows how to work with the module systems, and I don't have to deal with it.
Modules, number three. Then there's a way that you bring in the modules in the import statement, and that's also interesting. I can export stuff, and that's going to be available to other files. They can import it from my module as a file, as a module. But, if I want to bring something in, say I want to bring in that child process module, that's built into node. There are two ways to do that, import star as CP or whatever alias from child process, great. Now, I can do cp.spawn and stuff like that, fabulous. Or I could pick just the pieces that I want, and I could import spawn from child process. This is actually doing object deconstruction there, which is another cool thing that didn't make the cut.
So we're pulling out just the spawn property as its own identifier, great. Those are straightforward because child process exports an object with a bunch of functions and constants on it, like a good module should in my very strong but not entirely shared opinion. But then, not every module works like that - that would be too easy. Let's bring in a new package. This is always a challenge. When I print this status, I want it to be in a box. I want to use this package boxen, which I can get from npm. You can get everything on npm in triplicate, but you may not like any of them, that's okay. It's there or whatever it is. This boxen is beautiful. It does little ASCII art boxes. I really like it.
To get it, I need to run npm install boxen, and npm is going to declare it in my package.json. It's going to bring in boxen 2.0, it's going to put in my Node modules. Let's look at Node modules here for a minute. Node modules is a directory on my file system inside my project, and here it has boxen. It also has all this other crap. Why does it have all this other crap, npm, ls? This the tree of module dependencies. Look, my tiny module boxen depends on all of these. So here I have all of these. This is just normal. I think in our real projects we have at least 100. Welcome to dependency land, it's fine. Npm is a very important part of the language system of Node and of JavaScript now. Just like Maven is crucial to Java, and you may have heard bad things about npm, but they're getting less and less true. Npm now as a company behind it, it's totally improving. It's come a long way since that left pad incident, which I totally love; when someone deleted one tiny library with one function in it, and the whole internet went down, because heaven forbid we duplicate a function that's this long. No.
Anyway, npm has come a long way since then but it's still rich. The ecosystem is rich. One nice thing about having all the code on your file system is you can come look at the JavaScript, it just brings the code right in. JavaScript is the bytecode and it's readable, unlike Java bytecode, so that's kind of handy. Sometimes I just go ad some debugging to the JavaScript, write my Node modules. Whenever it goes away, the next time I run npm install, and it gets replaced by the real version, but it's totally great for debugging. I do like that about it. So that's a plus.
But this is a JavaScript module, and it does not export an object. No, it exports a function. Thank you, boxen. So that's fine - I wanted a function, but I can't import it like import star as boxen from boxen. No, I have to know that I need to say import boxen from boxen, and how do you know to do that? Well, you go look at the code or you go look at this page on npm, and you just observe that it uses itself as a function. We'll come back for that type error in a minute. I think this is actually going to work. Did anybody spot the bug? I haven't run it in a while, which was my mistake, but I did introduce a bug. It says status.kind is undefined. Indeed. Make everything else go away, JB. Status.kind is undefined because look, I gave it a type but I did not give it a value. This is a total trick.
Step one in this is make it yell at me. Sure enough, if I go to my strict options, there's one that says strictPropertyInitialization. Why this is separate from no implicit any, I have no idea. But there it is, and now when I go back to status, it's going to yell at me that I did not initialize kind. I need to say kind is the type of running and it's equal to running. This looks weird, but yes, you have to give it that constant string in type space and in runtime space. It gets into the JavaScript, and into the declarations. Now you know, and when this frustrates you, you will say "Oh, darn, now I feel extra stupid, because she told me about that." Just get your compiler to yell at you, it's better.
But speaking of the compiler yelling you, it's still yelling at me about boxen, because it could not find a declaration file for boxen. Because we said no implicit any, I actually wanted it to care about implicit any in my code. But, no, it's all the code in the world. No implicit any, this is a JavaScript library, people, it's in any. Just deal with it, but that's not explicit enough for it now, because I said no explicit any. And it wants me to go look at type/boxen. So what it needs is a declaration of the boxen module, it just has to have one, it's desperate for one in order to compile. Did I test it again? When I mean in order to compile, I mean compile without errors. TypeScript, because I fixed that problem. And it should, yes, there's the box.
So even though the compiler is still angry at me, I have a box. Can you all see the box? I love the box, I can make it bigger, I can make it yellow. I think boxen is really awesome. Anyway. But what's not awesome is that it hates me, about the boxen. If boxen were TypeScript module, it would have the types built-in, that's one place to get them. It would have the declaration files shipped with the package. But if boxen is not and it's not, then sometimes people put the declarations in this npm at types user, and there's a ton of them there. This is not one of them. So I need to tell it, I'm sorry, but this is just not going to be a thing.
Here is the spell, it's totally a spell. If I make a file, I don't think it matters what its name is, but it matters that it's the top level. And I say declare module boxen. That is the explicit any. If I want no implicit, I need to do things right. I can say declare module star. Let the JavaScript in, it's going to be okay. Trust me, I'll deal with the errors at runtime. Some people prefer that to be explicit, but this is going to make it happy. Now, it's an explicit any, it's compiling, it's out putting on JavaScript. Whatever, we're still in es5, so it's going to do complicated things with the imports to try to make them read well. I don't have to understand it fortunately. Here is our type declarations and there is the function takes a status, great.
Everything is happy now. I wanted to talk a little bit about distinguishing a package from a module, just because this is something that confused me. That's a good thing. A package is something that you publish to npm. It has a default module or main module which defaults to index.ts in the case of a TypeScript project, which becomes index.js and index.d.ts as opposed to a module, which is a file. I get those mixed up that's annoying.
But the other thing that's annoying is how different it is from Java when it loads these packages in these modules, because we're just going to do this abstractly. If this is my project, my TypeScript project, and I depend on boxen, which I do, and boxen depends on chalk, which it does. Chalk is just some ASCII art library thing. Then when npm does the install, it puts this stuff in Node modules, because it's matching what Node does when it loads it, and TypeScript has yet a third implementation of that, where tries to imitate nodes module loading. When you get into this, you will wind up spending half a day, at some point, learning about the intricacies of module loading in node.
At some point, we did this in Java. At some point, I had to learn class paths and class loaders. It's not necessarily worse, but it's very different. So for instance, what npm does is it doesn't put chalk there. It puts chalk up at the top level, because, in addition to looking in Node modules, and Node will look in your own Node modules directory first. If it doesn't find your boxen, it doesn't find chalk there, then it goes up a directory and says, "Hey, do you have a Node module?" It'll look in there and then it'll go up a directory and "Hey, do you have Node modules?" And it'll go look in there. So boxen winds up finding chalk in my Node modules directory.
This is npm trying to reduce duplication, because what if I also depend directly on chalk, then I would have chalk at the top level. As long as those are compatible versions, that's fine. Boxen and I can share a version of chalk, which is great, unless they're not compatible versions. In which case, boxen gets its own version of chalk. So here we have chalk1.x, maybe and I've got chalk 2.x, I'm making that up.
On one hand, this is not what would happen in Java. In Java, you have a class path, and you're going to find the first one of that class on the class path. And everybody's going to use that one unless you do magic class loader tricks, in which case you deserve what you get. But it's different here. Boxen is actually getting a different version of chalk, which is totally fine. If boxen just uses functions in chalk, it can have the ones it expects, and I can have the ones I expect, and everyone's happy, until boxen starts constructing something from chalk, giving it back to me, and I start passing that into my chalk.
What if that thing is a class? And what if that class has private or protected fields? So TypeScript does duck typing entirely, except in the case of classes with private or protected fields. Because private and protected, not a thing in JavaScript, not a thing in runtime. That has to be enforced entirely at compile time. If chalk exports a class which it doesn't, it's not that route, and then accepts a class into a function but we have had this problem in our libraries before we learned better, and that class is probably a protected fields. The only way TypeScript knows the class that chalk wants is the one being passed in is if it's in the same place on the file system like your personal file system.
You get this problem in Java. If you load a classroom, two different class loaders is the same class, and Java is like … But in node, or in TypeScript specifically, this is not node, this is TypeScript, even if it's the exact same version of the class, maybe you did a link to a local library, and it happens to have the exact same version of the class, but in a different location on the file system, TypeScript says, "Compile error private fields," super confusing. That's okay, because why are you exporting a class, a concrete class anyway with private fields? And why are you asking for that? Interfaces, people, this is just good OO design.
TypeScript is making it even more painful for you to violate the OO design principle of don't export concrete classes in your external API use interfaces. Maybe that's nice of it. But, now you're warned and it's just weird, and the point of the whole thing is really that you're going to get frustrated. When you switch to a new language it's not just the language. That's the easy part. It's a whole ecosystem. At some point, you're going to have to dig in and learn each part of that ecosystem.
When you're frustrated - this is my new lesson for myself this month actually - when I'm frustrated, when I'm cursing, when I'm banging on the computer and telling Node how stupid it is, it's time to slow down. It's time to step back and be like, "Okay, the world is telling you that you don't understand it." The way I think it should be is not the way it is. And in order to make it better, or much more likely to work within it, I'm going to have to step back, slow down and take the time to learn.
So don't be afraid of TypeScript, but also don't be afraid to just stop, and yes, spend half a day learning about how Node loads modules. Yes, it's esoteric and weird, but I promise it will make you a richer person. Thank you.
See more presentations with transcripts
Jessica Kerr
This content is in the Web Development topic
QCon San Francisco 2018
Choosing an Industrial USB Hub – Key Things to Consider
Charge, connect and manage mobile devices with Cambrionix managed USB hubs to help create perfect mobile experiences.
Excellent talk!
by M. G. /
I'm new to JS and even newer to TS.
I enjoyed the way this topic is presented, and the humour too!
Thank you @jessitron


Mango payasam is a creamy fruity dessert. It is simple and heavenly, the feel of biting mango pieces in between the creamy smoothness of the payasam. This dessert is preapred by swirling in ripe mango pulp or puree into a mixture of sweetened condensed milk. I decided to make a simple mango payasam for Aadi velli.
1). Boil the sago to translucent. Put in the sago pearls when the water is boiling hot, in order to get clear looking sago in the end, stir once a while as the sago will stick to the bottom.
2). Once done, pour the sago into a colander and quickly run through with cold water to stop the cooking. Scoop the sago into a bowl.
3). Peel and cube mangoes. Blend the chopped mangoes with milk. Then swirl the blended mangoes onto sago and mix well. Add the condensed milk in the sago-mango mixture and combine well.
4). Microwave for 3 minutes and top with chopped mangoes. Serve hot or cold. The smell and taste just lingers on.
# I added a few pieces of ripe mangoes to the payasam for variety, it gives the feel of natural fruity sweetness and intensify the mango flavor.
# Adjust the amount of milk according to consistency you want.
# If you are serving cold, add half cup of milk and serve, as it will thicken later.
# If you don't have condensed milk, just boil the regular milk till it reduces to half its volume and add sugar.
# Quantity of sugar can be increased or decreased depending on the sweetness of the mango.
# Can use ghee-fried cashews and raisins. You can add kesar (saffron) and Cardamom for making it more exotic!
# Canned mango pulp can also be used.
# Adjust the milk and sugar to suit your taste.
Thanks so much for sending it to my event!


I can't thank you men enough. What I thought was going to be a problem moving my mother in law turned into a. … you guessed it, a Purple Heart Moving Group !!Seriously though, whatever was very expert from initial contact to them pulling out of the driveway. Mike, Barry & Charlie (sorry if I got the name wrong!!) were wonderful. Client, mindful, thoughtful, PREPARED and quick.There was never a rough or dull moment. We joked and worked all the time and it made it not the hellish experience it could have been.I highly recommend these guys for any size move.ONCE AGAIN, Thank you !!
Purple Heart Moving Group are the best movers I've worked with till now. If you are moving, this is the company to use. Very punctual and friendly. Can't thank them enough!
My items are well cared and safely handled!
Highly recommend this moving company. The team was very informative, attentive and walked me through the process. The moving team arrived on time and worked quietly, quickly, and carefully to pack all of our belongings. Unloading went just as smoothly. I Highly recommend Purple Heart Moving Group.
They were efficient yet cautious enough for me not to worry about my delicates as they bubble wrapped it before the move. The movers were very thoughtful that they would place the boxes in specific areas that will help me with unpacking. It saved me so much time and effort at such an affordable rate and I would highly recommend Purple Heart Moving Group who want a stress-free move.
They were communicative, fast, and efficient. They were champs at bringing some pretty heavy items up several flights of stairs in sweltering heat! They even helped me reassemble some of my furniture, which I greatly appreciated. They made unloading my relocate a very easy experience. Would definitely use again.
They never stood still, were careful, listened to what stayed and what went, and couldn't have been nicer. They even helped set up a bed that had already been delivered to the new place. Everything was wrapped, nothing got damaged, not a broken glass – they made light work of what took me weeks to pack. I'd recommend them without hesitation.
I will not hesitate to refer their services.
They took extreme care with our furniture and worked fast and efficiently. We moved from a 2 bedroom apartment and they placed everything in the new home were we wanted it. We just needed 2 guys and the total move time was exactly 2 hours and the price was exactly what they quoted and definitely the best in town for I received multiple quotes. Would use them in the future and would recommend to family and friends. Thanks for a job well done!
They were efficient and communicative during the whole move making sure they got everything we wanted them to move. Super personable and professional. So glad we went with Purple Heart Moving Group because they gave us a stress free move! Thanks guys!
0 stars. All positive reviews they publish themselves. My retired military husband and I were charged over $21,000.00they use BAIT and Switch tactics and we have been informed that they are owned by the Russian mob. Most of the movers spoke Russian and they were rude, damaged our house and did a lost job packing our goods. I took photos of the inside of the truck when they arrived and it is obvious that we were overcharged by a lot.