Fans supporting the world's most promising athletes and sharing in their journey, emotionally and financially.

Meetlete

meetlete

Imagine you are driving at full speed on an empty highway and then oops… You are hitting an hour-long traffic jam. Your 8 hours trip becomes 9 hours. How does it feel? Now imagine that getting back to the full speed takes at least 30 minutes, not ~10 seconds. Right, your trip is now 9 hours and 30+ minutes, 90 minutes longer. The reason for 30+ minutes is that any intellectually intense work requires . Flow is a mental state when the brain is most productive. Getting into the flow state takes time. flow Being in the is like at full speed on an empty highway. Being is like hitting a traffic jam. flow driving interrupted Then you are driving forward and hitting two more 15-minute traffic jams hours apart. Think you lost another 15+30+15+30=90 minutes? Unfortunately, it is a lot worse, you lost the whole day… Getting into the requires a lot of energy. With every next distraction, it’s a lot harder. flow Photo by Jens Herrndorff That is why programmers and everyone else who is making great stuff don’t like meetings. I’m not suggesting that you shouldn’t talk within a the team. You should! No meeting can generate so much waste as people running in opposite directions. I’m also not suggesting that all communication should be in writing. It shouldn’t! As we know, most programmers also don’t like writing whole a lot of text. Verbal communication is by far the most efficient, but only if you can keep short, small and at the right time. The definition of short is 5–15 minutes. The definition of small is 2–4 people. Help programmers to do their best jobs There are two simple rules: . Agree on a daily hour that works best and use it on-demand for your short and small talks. For teams in different timezones you will have to select something on the intersection. Do all the talks either at the beginning or better at the end of the work day Like daily, weekly and monthly. Recurring meetings include more people than needed for longer than necessary. They also make it hard finding time to discuss things that matter the most at the moment. Stop scheduling any recurring group meetings. This is how ideal programmer’s calendar looks: Week schedule to maximize the flow state Put in place this schedule for all programmers in your team. And you can ignore/forget all the lengthy advice out there on how to run “great meetings”. is a Co-Founder of , a team video chat scheduler that helps makers to be in the flow most of the work time. Gene Podolyak Meetter Best content on this topic [1] Paul Graham: Maker’s Schedule, Manager’s Schedule [2] Al Pittampali: “Read This Before Our Next Meeting” | Talks At Google

Why Programmers Don’t Like Meetings (share this with your manager)

we learned the basics of the the . We saw how to set up some simple routes. Like Servant, there’s a bit of dependent-type machinery with routing. But we didn’t need to learn any complex operators. We just needed to match up the number of arguments to our routes. We also saw how to use an application state to persist some data between requests. Last week Spock library This week, we’ll add a couple more complex features to our Spock application. First we’ll connect to a database. Second, we’ll use sessions to keep track of users. For some more examples of useful Haskell libraries, check out our ! Production Checklist Adding a Database Last week, we added some global application state. Even with this improvement, our vistor count doesn’t persist. When we reset the server, everything goes away, and our users will see a different number. We can change this by adding a database connection to our server. We’ll follow the example and connect to an SQLite database by using Persistent. Spock tutorial If you haven’t used Persistent before, take a look at in our Haskell Web series! You can also look at our on Github for any of the boilerplate you might be missing. Here’s the super simple schema we’ll use. Remember that Persistent will give us an auto-incrementing primary key. this tutorial sample code share [mkPersist sqlSettings, mkMigrate "migrateAll"] [persistLowerCase|  NameEntry json    name Text    deriving Show|] Spock expects us to use a pool of connections to our database when we use it. So let’s create one to an SQLite file using . We need to run this from a logging monad. While we're at it, we can migrate our database from the startup function. This ensures we're using an up-to-date schema: createSqlitePool main import Database.Persist.Sqlite (createSqlitePool)

...

main :: IO ()main = do  ref <- newIORef M.empty  pool <- runStdoutLoggingT $ createSqlitePool "spock_example.db" 5  runStdoutLoggingT $ runSqlPool (runMigration migrateAll) pool  ... Now that we’ve created this pool, we can pass that to our configuration. We’ll use the constructor. We're now using an for our server, so we'll also have to change the type of our router to reflect this: PCPool SQLBackend main :: IO ()main = do  …  spockConfig <-    defaultSpockCfg EmptySession (PCPool pool) (AppState ref)  runSpock 8080 (spock spockConfig app)

app :: SpockM SqlBackend MySession AppState ()app = ... Now we want to update our route action to access the database instead of this map. But first, we’ll write a helper function that will allow us to call any SQL action from within our monad. It looks like this: SpockM runSQL :: (HasSpock m, SpockConn m ~ SqlBackend)  => SqlPersistT (LoggingT IO) a -> m arunSQL action = runQuery $ \conn ->   runStdoutLoggingT $ runSqlConn action conn At the core of this is the function from the Spock library. It works since our router now uses instead of . Now let's write a couple SQL actions we can use. We'll have one performing a lookup by name, and returning the of the first entry that matches, if one exists. Then we'll also have one that will insert a new name and return its key. runQuery SpockM SqlBackend SpockM () Key fetchByName  :: T.Text  -> SqlPersistT (LoggingT IO) (Maybe Int64)fetchByName name = (fmap (fromSqlKey . entityKey)) <$>   (listToMaybe <$> selectList [NameEntryName ==. name] [])

insertAndReturnKey  :: T.Text  -> SqlPersistT (LoggingT IO) Int64insertAndReturnKey name = fromSqlKey <$> insert (NameEntry name) Now we can use these functions instead of our map! app :: SpockM SqlBackend MySession AppState ()app = do  get root $ text "Hello World!"  get ("hello" <//> var) $ \name -> do    existingKeyMaybe <- runSQL $ fetchByName name    visitorNumber <- case existingKeyMaybe of      Nothing -> runSQL $ insertAndReturnKey name      Just i -> return i    text ("Hello " <> name <> ", you are visitor number " <>       T.pack (show visitorNumber)) And voila! We can shutdown our server between runs, and we’ll preserve the visitors we’ve seen! Tracking Users Now, using a route to identify our users isn’t what we want to do. Anyone can visit any route after all! So for the last modification to the server, we’re going to add a small “login” functionality. We’ll use the App’s session to track what user is currently visiting. Our new flow will look like this: We’ll change our entry route to . /hello If the user visits this, we’ll show a field allowing them to enter their name and log in. Pressing the login button will send a post request to our server. This will update the session to match the session ID with the username. It will then send the user to the page, which will greet them and present a logout button. /home If they log out, we’ll clear the session. Note that using the session is different from using the app state map that we had in the first part. We share the app state across who uses our server. But the session will contain user-specific references. everyone Adding a Session The first step is to change our session type. Once again, we’ll use a wrapper around a map. This time though, we'll use a simple type synonym to simplify things. Here's our type definition and the updated main function. IORef type MySession = IORef (M.Map T.Text T.Text)

main :: IO ()main = do  ref <- newIORef M.empty  -- Initialize a reference for the session  sessionRef <- newIORef M.empty  pool <- runStdoutLoggingT $ createSqlitePool "spock_example.db" 5  runStdoutLoggingT $ runSqlPool (runMigration migrateAll) pool  -- Pass that reference!  spockConfig <-    defaultSpockCfg sessionRef (PCPool pool) (AppState ref)  runSpock 8080 (spock spockConfig app) Updating the Hello Page Now let’s update our “Hello” page. Check out the appendix below for what our looks like. It's a "login" form with a username field and a submit button. helloHTML -- Notice we use MySession!app :: SpockM SqlBackend MySession AppState ()app = do  get root $ text "Hello World!"  get "hello" $ html helloHTML  ... Now we need to add a handler for the post request to . We'll use the function instead of . Now instead of our action taking an argument, we'll extract the post body using the function. If our application were more complicated, we would want to use a proper library for Form URL encoding and decoding. But for this small example, we'll use a simple helper . You can view this helper in the appendix. /hello post get body decodeUsername app :: SpockM SqlBackend MySession AppState ()app = do  …  post "hello" $ do    nameEntry <- decodeUsername <$> body    ... Now we want to save this user using our session and then redirect them to the home page. First we’ll need to get the session ID and the session itself. We use the functions and for this. Then we'll want to update our session by associating the name with the session ID. Finally, we'll redirect to . getSessionId readSession home post "hello" $ do  nameEntry <- decodeUsername <$> body  sessId <- getSessionId   currentSessionRef <- readSession  liftIO $ modifyIORef' currentSessionRef $    M.insert sessId (nameEntryName nameEntry)  redirect "home" The Home Page Now on the home page, we’ll want to check if we’ve got a user associated with the session ID. If we do, we’ll display some text greeting that user (and also display a logout button). Again, we need to invoke and . If we have no user associated with the session, we'll bounce them back to the page. getSessionId readSession hello get "home" $ do  sessId <- getSessionId   currentSessionRef <- readSession  currentSession <- liftIO $ readIORef currentSessionRef  case M.lookup sessId currentSession of    Nothing -> redirect "hello"    Just name -> html $ homeHTML name The last piece of functionality we need is to “logout”. We’ll follow the familiar pattern of getting the session ID and session. This time, we’ll change the session by clearing the session key. Then we’ll redirect the user back to the page. hello post "logout" $ do  sessId <- getSessionId   currentSessionRef <- readSession  liftIO $ modifyIORef' currentSessionRef $ M.delete sessId  redirect "hello" And now our site tracks our users’ sessions! We can access the same page as a different user on different sessions! Conclusion This wraps up our exploration of the Spock library! We’ve done a shallow but wide look at some of the different features Spock has to offer. We saw several different ways to persist information across requests on our server! Connecting to a database is the most important. But using the session is a pretty advanced feature that is quite easy in Spock! For some more cool examples of Haskell web libraries, take a look at our ! You can also download our for even more ideas! Web Skills Series Production Checklist Appendix — HTML Fragments and Helpers helloHTML :: T.TexthelloHTML =  "<html>\    \<body>\      \<p>Hello! Please enter your username!\      \<form action=\"/hello\" method=\"post\">\        \Username: <input type=\"text\" name=\"username\"><br>\        \<input type=\"submit\"><br>\      \</form>\    \</body>\  \</html>"

homeHTML :: T.Text -> T.TexthomeHTML name =  "<html><body><p>Hello " <> name <>     "</p>\    \<form action=\"logout\" method=\"post\">\      \<input type=\"submit\" name=\"logout_button\"<br>\    \</form>\  \</body>\  \</html>" 

-- Note: 61 -> '=' in ASCII-- We expect input like "username=christopher"parseUsername :: B.ByteString -> T.TextparseUsername input = decodeUtf8 $ B.drop 1 tail_  where    tail_ = B.dropWhile (/= 61) input

Spock II: Databases and Sessions!

Guts and experience, because sometimes the wrong choices are the right ones if you broaden time and system horizon. That argument can be misused by people wanting to take shortcuts — it is a grey area. But isn’t that where most interesting arguments lie? Let me elaborate with an example. At , we were building a Point of Sale system with card swipe, cash drawer, receipt printer and offline functioning. We should have used native java with client server architecture. That was and still is the tested and tried technology for POS. But we chose a pure web application. It was the wrong choice — we had hacks for card swipe, receipt printer, offline etc. It wasn’t neat. In-fact every workaround was questionable and cringeworthy at the time and made us question our choices deeply. HashedIn Three years later, the solution is still under use. While there were some hiccups e.g. when AWS S3 went down last month, the maintenance costs have been low. We were able to release complex feature like demand based pricing in less than a couple of months across all stores and regions that increased revenues and margins. Moreover, the chain acquired and expanded to 5 times its initial stores and opening a new store turned out to be super easy and inexpensive — squarely because of the wrong architecture. Get a laptop, chromebook or iPad with internet connection and just start! You can also read by Paul Graham, the founder of . He elegantly talks about competitive advantage of using LISP for building a website. No one would say it was the right choice. But like every wrong choice, it makes you different from everyone else and gives advantages no one else does. Beating the Averages YCombinator Summary It takes guts to make the wrong technology choice. And experience to workaround it’s weaknesses, while maximising strengths. If you pull that off, its no longer the wrong choice. It is the right one! I am working on MeetNotes.co , a meeting notes application for teams. If that sounds interesting, give it a spin here . If not, its cool. Hope you enjoyed the post though! is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

Do you have the guts to make the wrong technology choice?

You do. Whether its a delivery project, feature or sales budget, you have an estimate. It might be a really large range e.g. between $10 to $100,000 but that is okay. By definition an estimate isn’t exact. So its important to put a stake in the ground by putting an estimate. Even if its off, it lets you retrospect, improve your intuition and do a better job next time. Objection Putting an initial estimate down has a cognitive bias — . Maybe you can avoid it if you know about it! Otherwise, always give a range e.g. you can say “I believe it will take 30 to 70 hrs (or $30K to $70K) and I can give you a more accurate estimate if I know X”. Anchoring Summary Your estimate accuracy depends on your past experience and intelligence. If someone tells me they don’t know the estimate, I question both. So always give an estimate and then work to make it better. This post came about in a discussion with MeetNotes.co team. MeetNotes.co is a meeting notes application for teams trying to make meetings engaging. If that interests you, you can try it here . is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

I don’t know the estimate

ES6 introduces a new , called . Maps are designed as an alternative to using Object literals for storing key/value pairs that require unique keys, and provide very useful methods for iteration. JavaScript data structure maps Object literals as “Maps” Nothing is more fundamental in JavaScript than object literals. Creating a map of sorts is as simple as declaring it in code. var map = {"key1":"value1","key2":"value2"}map.key1; // == "value1" This will work in many situations, but there are problems with using object literals as maps. We may have keys that clobber Object prototype methods. var map = {"key1":"value1","key2":"value2"}map.toString() == "[object Object]"  // Correctmap.toString = "value3"map.toString(); // Uncaught TypeError: map.toString is not a function Another drawback of using object literals is all keys can only be strings. This works in many situations, but when attempting to use a primitive value as a string, the system will convert it to a string behind the scenes. This kind of magic which happens under the hood and without notification to the user can cause unexpected results, for instance, if the provided key is an array. map[[1,2,3]] = "value4" // the provided key is an arraymap['1,2,3'] = "value4" // the system has made the key a string Another problem with using object literals (pre-ES6), is property/key orders are not guaranteed. Just because you have added the keys in a certain order, does not mean they will remain in that order, when you iterate through the keys. var o = {}o.a = 1o.b = 2o.c = 3 for(key in o) console.log(key);// expected a,b,c - but not guaranteed to be in that order Objects also lacks a forEach method. If you are used to iterating arrays using .forEach(), objects cannot be iterated in this way. o.forEach // undefined Maps in ES6 ES6 Maps provide a new object for this purpose. You create a new map by calling . Iterable can be an array or any iterable object whose elements are key/value pairs. The provided key/value pairs are added to the new map. new Map([iterable]) var m = new Map()m.set('a', 1)m.set('b', 2)// {"a" => 1, "b" => 2} Map Properties and Methods Map provides a very convienent, property to get the size of the map. The size is also very convienently shown in the Chrome Dev console, along with the contents of the map. .size var m = new Map()m.set('a', 1)m.set('b', 2)m.size; // 2  Make sure to use .set so that size updates correctly m; // Map(2) {"a" => 1, "b" => 2} map.clear() Clears the map of all entries. map.delete(key) Deletes a key and returns if the delete was successful. var m = new Map()m.set('a', 1)m.set('b', 2)m.delete('a'); // truem.delete('c'); // false (key was not there to delete) map.get(key), map.has(key) Getting a key, and finding if a key is present. m.get('a'); // 1m.has('a'); // truem.has('z'); // false map.forEach(fn) Provides a convienient way to iterate the map. You can get keys, values, and the map itself very easily. var m = new Map()m.set('a', 1)m.set('b', 2)m.forEach((k, v, m) => console.log(`key:${k} value:${v} map:${m}`)) // key:1 value:a map:[object Map]// key:2 value:b map:[object Map] for..of Another option to iterate the map is to use syntax, which can easily provide access to the keys and values of the map. for..of for([key,value] of m)console.log(key + '=' + value)// a=1// b=2 m.keys() Returns a full-blown iterator, so you can iterate the keys one by one, on demand, using .next() var m = new Map()m.set('a', 1)m.set('b', 2) var iter = m.keys()iter.next(); // Object {value: "a", done: false}iter.next(); // Object {value: "b", done: false}iter.next(); // Object {value: , done: true} undefined m.values(), m.entries() The map Values and Entries can be iterated in the same way. Entries will give you an array of the kind [key, value]. var iter = m.values()iter.next(); // Object {value: 1, done: false}iter.next(); // Object {value: 2, done: false}iter.next(); // Object {value: , done: true} undefined var iter = m.entries()iter.next(); // Object {value: ["a", 1], done: false}iter.next(); // Object {value: ["b", 2], done: false}iter.next(); // Object {value: , done: true} undefined Maps give you alot of control over operations that need to be performed on the keys, values, or entries. 2d Arrays to Maps Maps can take 2d arrays in the constructor. Each array entry should have the format [key, value]. var arr = [['a', 1], ['b', 2]]var m = new Map(arr) m; // Map(2) {"a" => 1, "b" => 2} Non-Strings as keys You can use objects of all kinds as map keys. The system will not automatically convert the keys to strings as it does for object literals. This opens up a wide range of opportunities to do interesting things with maps. For instance, setting the document object as a key. var m = new Map() m.set(document, true) // uses the document object as a key// Map(1) {#document {} => true} m.get(document)// true Maps are an important new feature of ES6, and can be used in a wide variety of use cases for storing key/value pairs.

Stories, News & Mentions about MEETLETE

Meetlete’s Stories on HackerNoon