POPULARITY
2 episodes with Eric S Raymond
4 episodes with Eric S Raymond
2 episodes with Eric S Raymond
Lucas Collazo e Henrique Esteter entrevistam Fernando Ulrich, sócio da Liberta Investimentos e João Marco Cunha, gestor da Hashdex, pra um papo raiz sobre Bitcoin, a "pólvora monetária", e o cenário atual das criptomoedas, no episódio #265 do videocast.Adquira os livros recomendados pelos convidados no quadro Chamada de Margem:"The Cathedral & the Bazaar" de Eric S. Raymond: https://amzn.to/3B1KcIF"Ordem, Progresso, Dinheiro ou Groselha" de João Marco Braga da Cunha: https://amzn.to/3ZsHFkj________________Confira os novos investimentos do seu guarda-roupa com as melhores marcas da curadoria do Shop2gether com até 70% OFF:https://www.shop2gether.com.br/masculino?utm_source=mktinfluencia&utm_medium=ig&utm_content=stockpickers&utm_campaign=novembro_mktinfluencia_ig_stockpickersCódigo STOCKPICKERS15 para ter 15% OFF em todos os produtos de preço cheio.
Nikolay and Michael discuss why they chose Postgres — as users, for their businesses, for their careers, as well as some doubts. Here are some links to things they mentioned:Our episode on why Postgres become popular https://postgres.fm/episodes/why-is-postgres-popularDatabase Systems: The Complete Book (by Hector Garcia-Molina, Jeff Ullman, and Jennifer Widom) http://infolab.stanford.edu/~ullman/dscb.htmlOur episode on the Postgres startup ecosystem https://postgres.fm/episodes/postgres-startup-ecosystemWill Postgres Live Forever? (talk by Bruce Momjian) https://www.youtube.com/watch?v=iYVxWpyaGpA Constitutional Peasants from Monty Python and the Holy Grail https://www.youtube.com/watch?v=t2c-X8HiBngThe Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (book by Eric S. Raymond) https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar ~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is produced by:Michael Christofides, founder of pgMustardNikolay Samokhvalov, founder of Postgres.aiWith special thanks to:Jessie Draws for the elephant artwork
What is Open Source and why is it changing the world?'The Cathedral & The Bazaar' by Eric S. Raymond is a collection of essays describing the ethics, philosophy, history and implementation of the Open Source movement. As computer hardware became available to larger groups many wanted to play & tinker with their devices. Closed Source software (owned by companies) was restrictive so people worldwide began to collaborate on projects that was free to download and use. This resulted in a unique culture and economic incentives that gave rise to hugely influential software like the Linux operating system.Would love to hear your feedback and appreciate any support you wish to give :)Timeline:(0:00) - Intro(1:45) - Themes/Questions(9:02) - Personal Lessons(17:41) - Author & Extras(21:33) - Summary(24:12) - Value 4 Value(26:13) - Join Live!Value 4 Value Support:Boostagram: https://www.meremortalspodcast.com/supportPaypal: https://www.paypal.com/paypalme/meremortalspodcastConnect with Mere Mortals:Website: https://www.meremortalspodcast.com/Discord: https://discord.gg/jjfq9eGReUTwitter/X: https://twitter.com/meremortalspodInstagram: https://www.instagram.com/meremortalspodcast/TikTok: https://www.tiktok.com/@meremortalspodcast
As Jonah continues his search for Spanish gold, Sarah Isgur assumes control of the Remnant once again for some predictably eclectic conversation. She's joined by former Texas Rep. Will Hurd, who's also a security expert and national park enthusiast. After briefly discussing the ravages of age, they turn to America's immense beauty, the terrors of AI, the challenges of immigration reform, and everything in between. Are we in a new Cold War? Could Will be preparing for a shocking announcement? And most importantly, where in San Antonio should you get your taco fix?Show Notes:- Sign up for The Brief- Will: “Would China & Russia Attack Hawaii?”- Will's questionable national park tier list…- The nēnē- Eric S. Raymond's The Cathedral and the Bazaar
Welcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: Prizes for the 2021 Review, published by Raemon on February 10, 2023 on LessWrong. If you received a prize, please fill out your payment contact email and PayPal. A'ight, one final 2021 Review Roundup post – awarding prizes. I had a week to look over the results. The primary way I ranked posts was by a weighted score, which gave 1000+ karma users 3x the voting weight. Here was the distribution of votes: I basically see two strong outlier posts at the top of the ranking, followed by a cluster of 6-7 posts, followed by a smooth tail of posts that were pretty good without any clear cutoff. Post Prizes Gold Prize Posts Two posts stood noticeably out above all the others, which I'm awarding $800 to. Strong Evidence is Common by Mark Xu “PR” is corrosive; “reputation” is not, by Anna Salamon. I also particularly liked Akash's review. Silver Prize Posts And the second (eyeballed) cluster of posts, each getting $600, is: Your Cheerful Price, by Eliezer Yudkowsky. This notably had the most reviews – a lot of people wanted to weigh in and say "this personally helped me", often with some notes or nuance. ARC's first technical report: Eliciting Latent Knowledge by Paul Christiano, Ajeya Cotra and Mark Xu. This Can't Go On by Holden Karnofsky Rationalism before the Sequences, by Eric S Raymond. I liked this review by A Ray who noted one source of value here is the extensive bibliography. Lies, Damn Lies, and Fabricated Options, by Duncan Sabien Fun with +12 OOMs of Compute, by Daniel Kokotajlo. Nostalgebraist's review was particularly interesting. What 2026 looks like by Daniel Kokotajlo Ngo and Yudkowsky on alignment difficulty. This didn't naturally cluster into the same group of vote-totals as the other silver-prizes, but it was in the top 10. I think the post was fairly hard to read, and didn't have easily digestible takeaways, but nonetheless I think this kicked off some of the most important conversations in the AI Alignment space and warrants inclusion in this tier. Bronze Prize Posts Although there's not a clear clustering after this point, when I eyeball how important the next several posts were, it seems to me appropriate to give $400 to each of: How To Write Quickly While Maintaining Epistemic Rigor, by John Wentworth Science in a High-Dimensional World by John Wentworth How factories were made safe by Jason Crawford Cryonics signup guide #1: Overview by Mingyuan Making Vaccine by John Wentworth Taboo "Outside View" by Daniel Kokotaljo All Possible Views About Humanity's Future Are Wild by Holden Karnofsky Another (outer) alignment failure story by Paul Christiano Split and Commit by Duncan Sabien What Multipolar Failure Looks Like, and Robust Agent-Agnostic Processes (RAAPs) by Andrew Critch There's no such thing as a tree (phylogenetically), by eukaryote The Plan by John Wentworth Trapped Priors As A Basic Problem Of Rationality by Scott Alexander Finite Factored Sets by Scott Garrabrant Selection Theorems: A Program For Understanding Agents by John Wentworth Slack Has Positive Externalities For Groups by John Wentworth My research methodology by Paul Christiano Honorable Mentions This final group has the most arbitrary cutoff at all, and includes some judgment calls about how many medium or strong votes it had, among 1000+ karma users, and in some edge cases my own subjective guess of how important it was. These authors each get $100 per post. The Rationalists of the 1950s (and before) also called themselves “Rationalists” by Owain Evans Ruling Out Everything Else by Duncan Sabien Leaky Delegation: You are not a Commodity by Darmani Feature Selection by Zack Davis Cup-Stacking Skills (or, Reflexive Involuntary Mental Motions) by Duncan Sabien larger language models may disappoint you [or, an eternally unfinished draft] by Nostalgebraist Self-Integrity and the Drowni...
This week we dive into Tether, a stablecoin playing an important role in disrupting the legacy financial system, recently announced to be launching on Polkadot. Joe Petrowski, (Technical Integrations Lead, Web3 Foundation) speaks with Paolo Ardoino, CTO of Bitfinex and Tether. They discuss stablecoin trends, regulation and compliance with central banks, CBDCs (Central Bank Digital Currencies), the likelihood of central banks running on public blockchains such as Polkadot and Ethereum, achieving blockchain interoperability through common goods, and the upcoming launch of Tether on Polkadot. Highlights: 00:39 - Intro to Ardoino and Tether 06:38 - The issue of crypto arbitrage 08:57 - Stability by matching a dollar to the pace of Bitcoin 11:01 - Boom and innovation in the stablecoin sector 12:20 - The risks of decentralized stablecoins 13:30 - Achieving purchasing power stability 14:49 - The scope for non-US stablecoins 16:15 - Tether Gold, the precious-metal-backed stablecoin 20:34 - Individual assets vs. a managed basket of currencies 22:48 - Regulation and scrutiny from central banks 27:35 - Blockchain for central banks 28:40 - Tether’s criteria to deploy on a blockchain 30:15 - Common goods for blockchain interoperability 35:07 - Resilience through multiple blockchain support 36:49 - Tether to launch on Polkadot and Kusama Links: Paolo Ardoino on Twitter (https://twitter.com/paoloardoino) Tether on Twitter (https://twitter.com/Tether_to) Grenache (https://github.com/bitfinexcom/grenache) Ampleforth website (https://www.ampleforth.org/) Ardoino’s reading list: Eric S. Raymond, The Cathedral and the Bazaar Key Quotes: “I believe that you can not really understand as a CTO, all the nuances and complexities of your platform, if you stop coding” “the reason why our team decided to create Tether was to solve one problem I’m sure you are familiar with, that is crypto Arbitrage” “Why don’t we create a dollar that moves at the same pace as Bitcoin” “I would stay pure and not allow centralized stablecoins…. Crypto backed stablecoins are a very good value add to the sector, but I would prefer or would have preferred to not have decentralized stablecoins and centralized stablecoins.” “If you are using technology and the banking network, you have to respect the same standards, there is no other way around. That is why Tether has the function to freeze funds in order to cooperate with law enforcement. We do it quite openly, and we communicate when we do. Also, we did that to help many projects. There was an exchange hacked six months ago and we helped them to freeze thirty million dollars worth of Tether. There were many DEFI projects that were hacked and we worked with law enforcement to freeze those funds. That is what is happening in the banking world if someone steals funds from your bank account, the bank has the right to freeze your funds if you have stolen funds. We had to replicate the same functionalities in our centralized stablecoins. That is something that the decentralized coins don’t have and don’t need because they don’t use the banking system, we do, and we have to respect that.” “The idea that central banks will issue directly on Ethereum or Omni or Polkadot is quite realistic.” “You give more freedom to your users, you will gain traction.” “Supporting multiple blockchains makes the entire infrastructure resilient.” Special Guest: Paolo Ardoino.
Three good decades ago, Richard Stallman founded the free software movement and gave it a name. Two good decades ago there was a fork and Eric S. Raymond, Bruce Perens and others founded the open source software movement, and neglected to tell us who gave it a name. (it was Christine Peterson[0]) Ever since then, the free software side of the two movements has been careful to guard the boundary between the two, see Richard Stallman's essay "Open Source Misses the Point".[1] But lately a lot of people have increasingly been feeling that free software misses the point. Ironically a lot of this has been coming from the open source side of things, as the official free software philosophy has been firmly anchored with Stallman, and he hasn't been interested in moving his philosophy in more inclusive directions. For sure, there are a lot of people in free software who have been wanting to go in this direction as well. I've been thinking of it as a "free software plus", as it builds on the free software philosophy, but adds aspects of social responsibility. The fact that Stallman was forced to resign from being Free Software Foundation president two years ago was a sign that people inside free software cared about more than just the code and what freedoms it gives the recipient. A month ago, if you are listening to this on April the 20th 2021, a manifesto was published called "Towards A Communal Software Movement", and I'll get to that in a minute. I mentioned the names of the drivers of the previous movements, but this author has said "I intentionally left authors' names out of it"[2], and I think that makes sense. Part of the problems with previous movements has been this Great Man of History fallacy, which may have kept them focused and on track, but it has also held them back. The movement is young and has already changed names once as I was writing about it. The manifesto is now "Towards A Cooperative Technology Movement", and I have updated the shownotes and my commentary to reflect that. https://misskey.de/notes/8k0igd5tcd I see the difference between free software and cooperative technology similarly as the difference between open source and free software. There are certainly people within open source and on the Open Source Initiative board that look further than just the license, and treat open source like just another brand name for free software. But at its core, the Open Source Definition is all about the licensing and that document is the shared common ground for all open source. People write code for different reasons and there's a license and contribution model that allow them to come together without those differences of purpose getting too much in the way. So if the software and the license is "what" we're building, the philosophical documents of free software provide the guidance on "why" we are building it: We want to get away from proprietary software, we want to control our own computing, we want the freedoms to use, learn, modify and share, etc. Free software is about our freedoms. So just like "free" is right there in the name, maybe the "community" in "communal software" or the "cooperative" in "cooperative technology" is all about the "who": Who gets the freedom, who has the influence, who is affected. And again, lots of people in free software do care about community principles beyond code, care about social responsibility, but the shared baseline is the care for formal, technical and individual user freedom: If you receive the code, you are allowed the technical rights to update the code, the code or license should not restrict your freedoms, you, the recipient of the software, the hacker, the code contributor. It says nothing about practical user freedom and it says nothing about the community beyond the immediate user. That was my commentary. Now let's read the manifesto. https://cooperativetechnology.codeberg.page/ Before I saw the manifesto, I had written a draft list of aspects beyond licensing and contribution that determine the social good of your project: https://libranet.de/display/0b6b25a8-3060-61f6-28df-cae554943983 The conversations that led directly to the creation of the manifesto: https://social.polymerwitch.com/@polymerwitch/105934078911643041 https://fosstodon.org/@be/105952735879246194 [0] https://opensource.com/article/18/2/coining-term-open-source-software [1] https://www.gnu.org/philosophy/open-source-misses-the-point.en.html [2] https://fosstodon.org/@be/105952960559032774 Towards A Cooperative Technology Movement In response to the surprise, undemocratic reinstatement of Richard Stallman to the board of directors of the Free Software Foundation after his resignation in September 2019, the Free and Open Source Software movement is in the midst of a reckoning. The authors of this document recognize and honor the contributions Richard Stallman has made to this movement while unequivocally condemning his harmful behavior which has pushed many capable, dedicated people away from the movement. Regardless of what happens in the Free Software Foundation, we believe it is time to reflect on the shortcomings of our advocacy so we can grow into a more effective and inclusive movement for justice. Towards this end, we believe the movement will benefit from new terminology to describe what we do and what we aim for. Richard Stallman authored the free software definition in 1986. This term has always created difficulties communicating the ideas behind it because of the different meanings of the word "free" in English. Moreover, it is not the freedom of machines we are concerned with, but the freedom of humans. In response to this and other issues, in 1998, the term open source was promoted using an adapted version of the Debian Free Software Guidelines. The history of computing in the past 23 years have validated critiques that the term "open source" is insufficient for communicating the values behind it. The term "open source" and the ecosystem of Free and Open Source Software (FOSS) is today used by powerful companies, governments, and other institutions to harm people on enormous scales through surveillance and violence. These institutions use FOSS to minimize economic costs by benefitting from decades of work done by others, much of which was done by unpaid volunteers motivated by curiosity, passion, and the ideals of the FOSS movement. We believe a significant reason for the failures of both "free software" and "open source" to prevent this cooptation is that the men who coined and initially promoted these terms did not and do not critique capitalism. Richard Stallman has generally dodged the question of whether free software is opposed to capitalism. In the historical context of the United States in the 1980s, that may have been a wise decision. But that was then, and now it is 2021. The promoters of "open source" emphasize its compatibility with capitalism and go out of their way to distance "open source" from critiques of capitalism. We believe we need to build on the FOSS movement with an explicitly anticapitalist political movement which proactively collaborates with other movements for justice. We propose the term "cooperative technology" for this movement. By "cooperative technology", we mean technology that is constructed by and for the people whose lives are affected by its use. While this builds on the Free and Open Source Software movement, we aim to apply the same principles to hardware as well, although the criteria by which we evaluate hardware and software will of course not be identical. It is not sufficient to narrowly focus on the people who directly interact with computers. Cooperative software which is run on a server should not be controlled solely by the administrator of the server, but also by the people who interact with the server over a network. Similarly, the data generated by the technology and the data which it requires to function should be in the control of the people who are affected by the technology. Cooperative software that uses cameras should not be controlled solely by the people who own the cameras, but also the people who are observed by the cameras. Cooperative electronic medical record systems should not be designed for the interests of insurance companies or hospital administrators, but for the interests of patients and the clinicians who directly use it. We aim for a world in which all technology is cooperative technology and recognize that any amount of proprietary technology is in conflict with this goal. As an anticapitalist movement, we recognize that any institution which motivates people to put money, power, or self-interest above the welfare of humans is in conflict with our goals. Corporations are beholden to their shareholders who can hold the corporation legally liable for spending money in a way that is not intended to further enrich the shareholders. Other capitalist forms of enterprise have similar problems, incentivizing the profit of an elite few over the impact their activities have on others. We are not opposed to exchanges of money being involved in the creation or distribution of software or hardware. However, we should carefully consider the motivational structures of the institutions which fund technology development. Who benefits from the technology and who determines the priorities of its development and design? These are questions we ask about technology whether money is involved or not. It is in our interest to use safeguards to ensure that technology always remains controlled by the community which develops and uses it. Copyleft is one such safeguard, but it is insufficient on its own to prevent cooptation of our movement. Any cooperative technology project that receives funding from a for-profit enterprise must institute governance structures which prioritize community interests over profit in case there is a conflict between the two. We oppose business models which are in conflict with community interests such as "open core"/proprietary relicensing. Similarly, we are opposed to authoritarian and hierarchical governance structures of technology projects such as "benevolent dictators for life". Cooperative technology is developed democratically; no single individual should have ultimate authority in cooperative projects. While we recognize the need for leadership and private communication, discussions regarding cooperative technology should take place in public unless there is a specific reason for communications to be private. Organizations which advocate for cooperative technology should likewise operate democratically and transparently. We recognize that creating high quality technology requires much more than engineering skills. Cooperative technology is not only for people who have the skills of writing code (unless the software is for writing code such as a compiler) nor the skills to design hardware. Cooperative technology strives to be easy to use, including for people with disabilities, and acknowledges that this is best accomplished by continual dialog between engineers and users. Providing such feedback is a valuable way to contribute to the construction of cooperative technology without needing engineering skills. Ideally, the engineers of the technology should also be using it themselves. Moreover, there are many ways to contribute to cooperative technology without programming skills such as imagining ideas for new features, reporting bugs, writing documentation, graphic design, translation, promotion, and financial support. The free software movement has failed to create a world in which humans in technological societies can live without using proprietary software unless one chooses to live the ascetic lifestyle of Richard Stallman. Expecting people to not use any proprietary technology and judging people for not meeting this standard pushes people away from our movement. People who are coerced into using proprietary technology deserve our empathy and invitation into our movement, not condescension. Let us criticize institutions which pressure people into using proprietary technology, not the people who choose to use it. To that end, we strive to use cooperative technology tools as much as possible in our efforts to build cooperative technology. The purpose of this document is not to proclaim a legalistic set of criteria for determining what technology is cooperative and what technology is not. History has demonstrated that this is not an effective political tactic for the reasons explained above. The free software definition and the open source definition are useful criteria for evaluating copyright licenses for code, but an effective political movement cannot be so narrowly focused on legalistic and binary judgements of copyright licenses to judge whether certain technology aligns with our goals. We believe the focus of the cooperative technology movement should be on the practical impacts that the use of technology has on humans and the universe we inhabit. The scope of this extends beyond humans and must consider the environment around us. Moreover, we believe it is counterproductive to have a small self-appointed group of privileged men determine what our movement's terminology, goals, and tactics are. We encourage anyone interested in building a better world through technology to engage in discussions with your own communities about what you want "cooperative technology" to mean. While we agree with the Ethical Software Movement that we must resist when our efforts are coopted for unjust purposes, we reject putting restrictions on the ways people may use software through copyright licenses as a wise tactic for achieving our goals. The history of the Free and Open Source Software movement has shown that the proliferation of incompatible copyright licenses which prohibit software from being legally combined creates more obstacles than opportunities for our movement. Any new copyright licenses for use with cooperative software must be written with this consideration in mind to intentionally avoid fracturing the software ecosystem. Adopting incompatible copyright licenses for different software would make it easy for our adversaries to divide and suppress the movement. Language is constructed collectively and is always evolving. It is counterproductive to our movement to refuse to collaborate with people because they use the words "open source" or "free software" to describe their work. They may even disagree with the entire premise of this document. That does not mean we should not work together towards shared goals, but we should be conscious that our goals may not perfectly align and this may cause tension in our communities from time to time. We invite anyone to collaborate with us who is interested in building a better world and treats us and others in our communities with dignity and respect. This document is licensed under the CC0 license. Contributions are welcome on Codeberg. If you disagree with parts of this, feel free to fork it and say what you want to say.
For January, we read The Cathedral and the Bazaar by Eric S. Raymond. We discuss our experience with open source software, Microsoft going into open source, Eric's predictions, why we didn't like chapter 3, and Eric's, RMS, and Linus Tovald's bad behaviour. We also have a tangent about how great Windows XP is! February - Blitzed: Drugs in the Third Reich by Norman Ohler March - Black Skin, White Masks by Frantz Fanon April - The Assassination of Fred Hampton by Jeffrey Haas
For December we read The Caliban and the Witch! We do a brief rundown of the book, discuss interesting facts we learned from witch-hunts, we thought of why men didn't help, occultism in the contemporary times and occultism and capitalism. We also had a special guest of Jimmy's cat! January Book - The Cathedral and the Bazaar by Eric S. Raymond
The culture of your programming community directly impacts your professional success. As Thunderbolt Labs Founder Randall Thomas explains in this episode, a community that practices openness and which warmly welcomes its newer members leads to greater career happiness. We open our chat with Randall by exploring his start in coding and how he discovered Elixir. He shares some of the teething problems that he had moving from Ruby to Elixir before we touch on how learning other languages expands your ability to both appreciate and code in languages that you’re already fluent in. Following this, Randall explodes the myth of the genius polyglot programmer by sharing his take on why all coders are polyglots. As the Thunderbolt CEO, we ask Randall how his company adopted Elixir. He provides listeners with insights into how they introduced Elixir into their practice without affecting existing projects. After highlighting the efficiency of Elixir and how community affects the feel of a language, we compare the culture and challenges of Ruby, JavaScript, and Elixir. Near the end of the episode, Randall reflects on why experts make for poor teachers. For Randall, Elixir gives his company a competitive advantage. Tune in to hear Randall’s perspective on why community matters and for his top advice on teaching your team Elixir. Key Points From This Episode: Introducing Thunderbolt Labs Founder and CEO, Randall Thomas. Randall shares how he discovered coding and engineering. Hear how Randall first heard about Elixir and how he picked up the language. Exploring common challenges moving from Ruby to Elixir. How learning new languages can deepen your understanding of languages that you already know. Why there’s no such thing as the ‘genius polyglot programmer.’ Details on why Randall’s company began gravitating towards Elixir. How communities affect the ‘feel’ of a language. Why no one actually writes in JavaScript anymore. Randall gives his take on why Elixir is a god-send for certain programmers. Insights into how Randall integrated Elixir into his company. The challenge of learning Elixir versus the ease of learning JavaScript. How Randall sold his clients on Elixir and the benefits of having clients that trust you. Randall’s top tips on helping your developers learn Elixir. Why Elixir gives Randall’s a strategic advantage. The importance of having non-experts explain things to you. How your coding community can impact your happiness and career success. Links Mentioned in Today’s Episode: SmartLogic — https://smartlogic.io/ Randall Thomas on LinkedIn — https://www.linkedin.com/in/randall-j-thomas/ Randall Thomas on Twitter — https://twitter.com/daksis Thunderbolt Labs — https://www.thunderboltlabs.com/ Episode with Miki Rezentes — https://smartlogic.io/podcast/elixir-wizards/s4e16-rezentes/ Gödel, Escher, Bach on Amazon — https://www.amazon.com/B6del-Escher-Bach-Eternal-Golden/dp/0465026567 Stephen Hawking — https://www.biography.com/scientist/stephen-hawking William James — https://plato.stanford.edu/entries/james/ Bertrand Russell — https://plato.stanford.edu/entries/russell/ Barcelona Ruby Conference — https://twitter.com/baruco José Valim — https://twitter.com/josevalim Programming Elixir on Amazon — https://www.amazon.com/Programming-Elixir-1-6-Functional-Concurrent/dp/1680502999 Dave Thomas — https://pragdave.me/ ElixirConf — https://2020.elixirconf.com/ ‘(UN)Learning Elixir’ — https://www.youtube.com/watch?v=o54EurlzK8o Bruce Tate — https://www.linkedin.com/in/bruce-tate-a836b/ Grox.io — https://grox.io/ Eric S. Raymond — http://www.catb.org/~esr/ Stack Overflow — https://stackoverflow.com/ Medium — https://medium.com/ Engine Yard — https://www.engineyard.com/ Douglas Crockford — https://www.crockford.com/about.html Yehuda Katz — https://www.linkedin.com/in/yehudakatz/ Blake Mizerany — https://www.linkedin.com/in/bmizerany/ The Pragmatic Studio — https://pragmaticstudio.com/ Stuff Goes Bad: Erlang in Anger on Amazon — https://www.erlang-in-anger.com/ Frederic Trottier-Hebert — https://www.linkedin.com/in/fredth/ Stu Holloway — https://www.linkedin.com/in/stu-holloway-linvio/ Paul Graham — http://www.paulgraham.com/ Hackers and Painters on Amazon — https://www.amazon.com/Hackers-Painters-Big-Ideas-Computer/dp/1449389554 Lonestar Elixir — https://lonestarelixir.com/ Turing.io — https://turing.io/ Sundi Myint on Twitter — https://twitter.com/sundikhin Justus Eapen on Twitter— https://twitter.com/JustusEapen Eric Oestrich on Twitter — https://twitter.com/ericoestrich Special Guests: Randall Thomas and Sundi Myint.
For November, we read Blood, Sweat, and Pixels by Jason Schreier. We talk about crunch, wooden voice acting, game making under socialism! Things mentioned in the podcast: Youtuber Matt McMuscles https://www.youtube.com/c/MattMcMuscles Valve Employee Handbook https://www.valvesoftware.com/en/publications Unity https://unity.com/ Godot https://godotengine.org/ December - Caliban and the Witch by Silvia Federici January - The Cathedral and the Bazaar by Eric S. Raymond
For October, we read Lexicon of Terror by Marguerite Feitlowitz. We discussed the language that was used, the interviews, and how does a society move on past these horrors. And also Top Gun movie sequels. Other podcasts/youtubers mentioned: Bad Empanada Behind the Bastards Seriously Wrong Upcoming books - November - Blood, Sweat and Pixels by Jason Schreier December - Caliban and the Witch by Silvia Federici January - The Cathedral and the Bazaar by Eric S. Raymond
Aktuell wird wieder einmal über die Chancen von Linux für Jedermann diskutiert, denn mit Eric S. Raymond hat ein Urgestein der Szene den Sieg von Linux auf dem Desktop-Markt vorhergesagt. Auch wenn der dabei über die Strategie von Platzhirsch Microsoft spekuliert, kann er sich doch auf eine Hinwendung der Windows-Entwickler hin zu dem ehemaligen Intimfeind berufen. Wurde Linux in Redmond lange belächelt, so werden die Stärken von Linux inzwischen anerkannt und statt Stinkefinger gibt es offene Arme. So etwa beim Windows Subsystem for Linux (WSL), das in seiner neuesten Inkarnation ein vollwertige Linux-Umgebung samt Linux-Kernel stellt. Aber wie steht es eigentlich um Linux und woran arbeiten die vielen Helfer, während Linux auch bei Windows mehr und mehr einen Fuß in der Tür bekommt? Das besprechen wir in einer zusätzlichen #heiseshow am Dienstagabend. Worauf liegt derzeit der Fokus bei der Linux-Entwicklung? Welche Projekte sind abgeschlossen und was wünschen sich die Nutzer? Was hält die Entwicklergemeinde von der veränderten Einstellung bei Microsoft? Wie werden die Beiträge von Microsoft & Co. zum Code und zur Entwicklung bewertet? Was erwartet man für die nahe und ferne Zukunft? Wird Linux tatsächlich den Desktop-Markt erobern? Und wie wichtig wäre das überhaupt? Diese und viele weitere Fragen – auch der Zuschauer – besprechen Kristina Beer (@bee_k_bee) und Jürgen Kuri (@jkuri) diesmal am Dienstagabend um 17 Uhr mit Thorsten Leemhuis (@kernellogger) vom Kernel-Log und Keywan Tonekaboni (@tonekaboni) von der c't in einer neuen Folge der #heiseshow. Alternativ wird der Stream auch auf Twitch.tv/heiseonline gesendet. === Anzeige / Sponsorenhinweis === Diese Ausgabe der #heiseshow hat einen Sponsor: Blinkist ist eine App, mit der man mehr als 3.000 Sachbücher in je nur 15 Minuten lesen oder anhören kann. Es gibt neue Ratgeber und Klassiker aus mehr als 25 Kategorien wie Wissenschaft, Technologie, Zukunft und persönlicher Entwicklung, mit Tipps und Tricks für Alltag und Beruf. Jeden Monat kommen etwa 40 neue "Blinks" hinzu. Für alle, die nach den Blinks tiefer ins Thema einsteigen wollen, gibt es nun auch Hörbücher in voller Länge. Zuschauer der #heiseshow erhalten einen 25-%-Rabatt auf das Jahresabo "Blinkist Premium" über den Link blinkist.de/heiseshow. Blinkist kann sieben Tage lang kostenlos getestet werden. === Anzeige / Sponsorenhinweis Ende ===
Aktuell wird wieder einmal über die Chancen von Linux für Jedermann diskutiert, denn mit Eric S. Raymond hat ein Urgestein der Szene den Sieg von Linux auf dem Desktop-Markt vorhergesagt. Auch wenn der dabei über die Strategie von Platzhirsch Microsoft spekuliert, kann er sich doch auf eine Hinwendung der Windows-Entwickler hin zu dem ehemaligen Intimfeind berufen. Wurde Linux in Redmond lange belächelt, so werden die Stärken von Linux inzwischen anerkannt und statt Stinkefinger gibt es offene Arme. So etwa beim Windows Subsystem for Linux (WSL), das in seiner neuesten Inkarnation ein vollwertige Linux-Umgebung samt Linux-Kernel stellt. Aber wie steht es eigentlich um Linux und woran arbeiten die vielen Helfer, während Linux auch bei Windows mehr und mehr einen Fuß in der Tür bekommt? Das besprechen wir in einer zusätzlichen #heiseshow am Dienstagabend. Worauf liegt derzeit der Fokus bei der Linux-Entwicklung? Welche Projekte sind abgeschlossen und was wünschen sich die Nutzer? Was hält die Entwicklergemeinde von der veränderten Einstellung bei Microsoft? Wie werden die Beiträge von Microsoft & Co. zum Code und zur Entwicklung bewertet? Was erwartet man für die nahe und ferne Zukunft? Wird Linux tatsächlich den Desktop-Markt erobern? Und wie wichtig wäre das überhaupt? Diese und viele weitere Fragen – auch der Zuschauer – besprechen Kristina Beer (@bee_k_bee) und Jürgen Kuri (@jkuri) diesmal am Dienstagabend um 17 Uhr mit Thorsten Leemhuis (@kernellogger) vom Kernel-Log und Keywan Tonekaboni (@tonekaboni) von der c't in einer neuen Folge der #heiseshow. Alternativ wird der Stream auch auf Twitch.tv/heiseonline gesendet. === Anzeige / Sponsorenhinweis === Diese Ausgabe der #heiseshow hat einen Sponsor: Blinkist ist eine App, mit der man mehr als 3.000 Sachbücher in je nur 15 Minuten lesen oder anhören kann. Es gibt neue Ratgeber und Klassiker aus mehr als 25 Kategorien wie Wissenschaft, Technologie, Zukunft und persönlicher Entwicklung, mit Tipps und Tricks für Alltag und Beruf. Jeden Monat kommen etwa 40 neue "Blinks" hinzu. Für alle, die nach den Blinks tiefer ins Thema einsteigen wollen, gibt es nun auch Hörbücher in voller Länge. Zuschauer der #heiseshow erhalten einen 25-%-Rabatt auf das Jahresabo "Blinkist Premium" über den Link blinkist.de/heiseshow. Blinkist kann sieben Tage lang kostenlos getestet werden. === Anzeige / Sponsorenhinweis Ende ===
Unfettered Freedom is a video podcast that focuses on news and topics about GNU/Linux, free software and open source software. On this freedom-packed episode:0:00 - Intro2:04 - Eric S. Raymond has some predictions about Windows 10 and Linux.9:04 - The Respondus Lockdown Browser.15:26 - DRM is designed to limit your rights.19:31 - Are there any "free as in freedom" webmail providers?23:08 - Every distro is awesome! (or is it?)30:01 - Outro and a THANK YOU to the patrons!REFERENCED:► https://www.zdnet.com/article/open-sources-eric-raymond-windows-10-will-soon-be-just-an-emulation-layer-on-linux-kernel/► https://web.respondus.com/he/lockdownbrowser/► https://defectivebydesign.org/► https://www.fsf.org/resources/webmail-systems► https://www.reddit.com/r/linux/comments/j07qwy/every_distro_is_awesome/AUDIO VERSION OF THIS PODCAST:https://www.buzzsprout.com/1263722/https://open.spotify.com/show/2dWHD35...https://podcasts.apple.com/us/podcast...RSS FEED FOR UNFETTERED FREEDOM:https://feeds.buzzsprout.com/1263722.rssMUSIC ATTRIBUTION:"Key To Your Heart" by The Mini Vandals (from the YT Audio Library)CREATIVE COMMONS LICENSE:This video is licensed with a Creative Commons CC BY license. By marking this original video with a Creative Commons license, I am granting the community the right to reuse and edit that video. Freedom, baby!WANT TO SUPPORT THE CHANNEL?
My guest today is Audrey Crane. Audrey is a partner in DesignMap, a UX strategy and digital product design consultancy based in San Francisco. Audrey recently published a book called What CEOs Need to Know About Design, and in this conversation, we talk about the evolving role of design in organizations and why this book is needed now. Listen to the full conversation Show notes DesignMap TRS-80 Ashton-Tate Apple Netscape Hugh Dubberly Dubberly Design Office Hypercard What CEOs Need to Know About Design: A Leader's Guide to Working With Designers by Audrey Crane About Face: The Essentials of Interaction Design by Alan Cooper, Robert Reimann, David Cronin, and Christopher Noessel The Design of Everyday Things by Don Norman Learning GNU Emacs: A Guide to Unix Text Processing by James Elliott, Eric S. Raymond, Marc Loy, Debra Cameron, and Bill Rosenblatt Zoom Accenture The Informed Life Episode 22: Andrea Mignolo on Designerly Ways of Being Some show notes may include Amazon affiliate links. I get a small commission for purchases made through these links. Read the full transcript Jorge: So, Audrey, welcome to the show. Audrey: Thanks Jorge! Glad to be here. Jorge: Well, it's great to have you. For folks who might not know you, can you please introduce yourself? Audrey: Yeah. My name is Audrey. I'm a partner at DesignMap. We're a design consultancy that does UX strategy and digital product design based in San Francisco. Jorge: And I'll say right off the bat that I've had the pleasure to work with you all over the last couple of years, and it's been a really great experience and the work that's come out I think is fantastic, so kudos on that. What is your background? Like how did you get to DesignMap? Audrey's background Audrey: Well it's kind of a long and winding road. I went to college and studied theater and math, specifically, pure mathematics. So, I wanted to get a theater degree, and my mother told me, you can do that, but you have to double major. So, I studied those two things, but my father actually was a computer programmer from the very early days. So, we had a Radio Shack TRS-80 in our house. I wrote computer programs on that. Very basic things, literally in BASIC, to play with as a kid. And so, I was always around tech. Like my summer jobs, I would do QA for Ashton-Tate or whatever company he happened to be working for. So, I was maybe the oldest person to grow up, or one of the oldest people who grow up with technology. And he had a great relationship with Apple. They would ship him computers before they released them, and he would write software for that computer, so they'd have something to ship the computer with. So, we had Apple IIs and Macs and stuff. So, after I graduated from college, I really wanted to get a day job that paid, and my dad was in Silicon Valley, so I went out there and I worked for a couple of companies, and this was in the early nineties, so kind of a long time ago now. And I ended up, through a series of incredible strokes of luck at Netscape and Hugh Dubberly, who we both know, was there and saw the double major on my resume actually, and said, that sounds ridiculous. I would like to meet this person. And so, I was, “Thanks mom!” Hugh interviewed me and brought me on actually as a producer there, but there I got the chance to understand “capital D” design. Which I think is a wonderful place for people who like to do right-brain and left-brain things. And so, after Netscape, I left and took some time off and then he started Dubberly Design Office. So, I got to be employee number one there and worked there for seven years and then left. And worked inside companies, running design teams and freelancing and doing various things, and then came to DesignMap, 10 years ago now, actually. And became a partner, I don't know, eight years ago with my other three partners there. “Capital D” design Jorge: You use the phrase “capital D” design, and I'm wondering if we could expand on that. Like what do you mean, “capital D” design? Audrey: Oh, now that I hear it played back to me, that sounds kind of ostentatious. But you know, Hugh used to say, “everybody is a designer,” and he was right. We all pick out what clothes we're going to wear in the morning. That's a design challenge by itself. But I think meeting Hugh and all of the designers that he introduced me to, which was – some of it was graphic design, but some of it was HyperCard, and sort of processes and workflows and that kind of thing – really introduced me to the idea that you could do this for a living, not necessarily as an artist. And of course, we love artists, but there's this, this other way of doing it. Which is to say, working within boundaries to solve problems or work on problems. Jorge: I'm understanding it correctly, it's the notion that somehow design work transcends any one particular branch of design or area of design or what people interpret as being an artifact of design? Audrey: I think that maybe the distinction in my mind is, designed for yourself versus designed for others. Jorge: Got it. Okay. Yeah, that's an important call-out, right? What is the ultimate intent of the design process? Audrey: Right. Decorating my bedroom is design. It's for me. I guess, arguably, picking out what clothes I'm going to wear… maybe it's for me, maybe it's for other people, but certainly when we're talking about service design or software design, experience design, we're talking about others. Jorge: Part of the reason why we're talking about this is that you've recently published a book about design, and I was hoping that you could tell us about it. Audrey's book Audrey: Yeah. So, the book is called What CEOs Need to Know About Design. The subtitle is, A Business Leader's Guide to Working with Designers published with Sense and Respond Press. So that's Josh Seiden and Jeff Gothelf. And this is one of that series of books that's pretty short, you can read it in less than an hour. But it came about because I got a call a couple of years ago now from a CEO of a small company, maybe 200 people, and he said, “I used to be an engineer, so I understand technology, and I've been promoted and over time I've learned about HR and finance and operations and marketing. I hear that design is important. I understand that it can move the needle for my business, based on reports that I'm reading and colleagues that I'm talking to. But I don't know what I need to know about design or how to know it. So, can you guys help me do that?” And that call kind of hit me like a bolt of lightning. Of course, he's asking this question and why aren't more people asking this question? I think we as designers – and maybe this is true of all professions, I'm not really sure – but we have conferences and we write blog posts, but a lot of it – and acknowledging the irony of me saying this as we're in a podcast with that designer talking to a designer – like it's a lot of like designers speaking to designers. And we're talking about really good, important, PhD-level stuff, which is great for furthering our profession and making us better at what we do, but it's not great for somebody who wants to know, honestly, what's a wireframe? And we have had, specifically at DesignMap and other places where I've worked as a consultant, we've had clients say, why is it all black and white? Or, when are we going to get the design maps? Like thinking that, like, oh, there's… there are maps. So many kinds of maps, but design maps are not one of them. And it's great that they're asking the question and I fret about how they feel when we answer it. And I was at a conference sort of pounding my fist about this in a chat with Josh and saying like, what are these men and women supposed to do that really want to know how to apply it in a business sense and don't even really know the basics? We can't… We can't hand them About Face. That's ridiculous. We can certainly ask them to read The Design of Everyday Things, but that's not quite it either. So, what are we doing to bridge the gap and to make it a little bit easier to work with us? And I think designers are doing a pretty good job speaking business more. And I also think that we can do better at helping them speak design more and understand, not just design for design's sake, but design because it's going to make a difference. It's going to help them personally, their business and their customers be more successful, or it has the potential to. So that's the genesis for the book. Jorge: So, what I'm hearing you say there is that the question that this is seeking to help answer is, what is it for? Like what's the purpose of this, right? Is that a fair take on it? Audrey: Yeah, I mean, it's certainly true, “what is it for?” is part of the book and there's a section that's just called the ROI of Design. There's also the how, and so it's not how do you design, but how do you build a design team and then work with that design team successfully as opposed to how do you design, which is what, so much of the content out there is about. So, there's a ton of material right now out there about the ROI design. And I guess I was lucky that I could just say point to a few reports and say, this is how it impacts the return on investment from my perspective. And here's a couple of good reports just to prove it to you. And then beyond that, it's how do you hire a team? And as part of this, I talked to several business leaders that I thought of as really great advocates for design CEO's, product managers. And it was interesting in those interviews that they had sort of 90% of the picture from my perspective. And then there'd just be these giant gaps. And again, this is my perspective, but they'd say, “I had a successful exit and I credit that to having a great design team.” “We had an acquisition that was fantastic, and that was a fourth hire than I made.” And then they would say in the next breath, “Of course, when the product managers make wireframes, they don't look quite as nice, but…” and I'm like, “Wait, wait, wait, wait, wait. What? What are you…?” And doing a little digging in there, it turns out the designers are only around for the first few weeks of the project and then they go away. And so, trying to just create a level playing field, and you would be surprised, I think, how often… With our clients, we sometimes say, “Hey, we have a suite of workshops we'd be happy to offer one to use as part of our work together.” And one of them is feedback. And it is by far the most selected workshop. And at first, I was surprised because, you just sit back and kind of give your opinion, right? But, certainly one could do better than just sitting and giving one's opinion and it's, how would a product manager know what kinds of things are useful in a feedback session? What kinds of things are appropriate in a feedback session? Are they thinking that this room full of people is expecting them to be extremely knowledgeable about design? I mean, we're not asking them to do code reviews. Right? So, it's these kinds of things where I struggle with the book a little bit because it's 15,000 words, and if you said, okay, write 15,000 words about everything that anybody needs to know about the law in the United States, it would be a ridiculous assignment. And yet I gave myself, I think, a not quite as rigid, but a pretty ridiculous assignment. So, there's a lot that's left out. There's a lot that's over simplified. There's a lot more than I wanted to say. But at least we can have this basic shared understanding, which is how might a good feedback session look? What kinds of things might you ask designers in the interview process? And that's another good example is, how often we come across companies hiring designers without a designer on staff, and they're not doing portfolio review. They're just interviewing them kind of for culture fit or I'm not even sure what. So just getting this kind of basic shared understanding can be really helpful. And then teams and individuals can build from that is my hope. Jorge: Yeah. Having read the book, what it reminded me of – and I'm just going to try to bounce it back at you, because I think that this is the role that it fits – is it reminded me of how O'Reilly has these – O'Reilly the publishing house – has these very deep books on various technical tools and subjects and stuff, right? And, one that I always remember is, they have the book for GNU Emacs, this text editor. And it's a thick book, right? Because that's such a complex thing. But then they also have this other line of books that are like pocket references for these things that are… It's not that they're outlines – they're more fleshed out than an outline – but it really is the essence of what you need to know to either refresh your memory or find out what the basics are for the subject. And to your point, there are other books that are the equivalent of the big tome, and that's not what this is. This seems meant to be kind of an introduction for very busy people to the essentials that they need to know to understand both the relevance of design in their organizations, but also to operationalize it, right? Audrey: Yes. That's perfect. Thank you! Okay. I should have written that down. I'll listen to the recording later. Jorge: So, I'm wondering about a couple of things here. One is, the changing role of design. Because you and I have been in this industry long enough where we've seen organizations engage with design in different ways; like the way that organizations hire for operationalized design has evolved over time. And in the book, you cover several different ways in which organizations can engage designers. As you were saying earlier, they can build an internal team, they can hire a company like DesignMap, right? And that mix has been evolving over the past few years. Like over the last decade, there's been a significant move towards organizations building internal design functions, right? So that's one thing that I'm curious about, and I know that you do touch it a little bit on the book, but this book is meant as an introductory guide, right? So, I'm wondering about your thoughts on that. And then, I'm also wondering how the role of design might evolve given the current situation, if any. Design and the pandemic Audrey: Yeah. Well, maybe we can talk about the current situation first. I mean, it's really interesting how these tools that were business critical, like Zoom, but weren't what the whole company was running on? Like the role of those tools has really changed and alongside it, the massive change in the user base for those, so the people using Zoom. My Zoom account in any one day is used by my four-year-old. Tomorrow, they're actually going to the zoo; they're going to have like a guided tour of the zoo. And then, it's used by our office manager. It's used by me, who uses it all the time. And it was used actually a week and a half ago by my grandmother and my husband's grandfather to join our wedding. So, there's this massive growth in audience needs, audience goals, audience background and technical capability and interest level. And so, that's huge. Actually, I was just talking to a friend who's quickly repurposing a mobile ophthalmology tool to support a hundred percent remote doctor appointments with the ophthalmologist. So, these things are changing really dramatically. And I think, obviously, as we're seeing features updated in – just again to stick with Zoom as an example – we're seeing features updated weekly, so design can be really helpful. Research and design specifically can be really helpful in responding to that. Research is very interesting right now. I personally feel that when you're doing generative research, certainly in my experience, fundamental insights that really changed how a product was going to succeed or not, those insights were about how the product fit in with people's larger lives, and it's hard sometimes to get to that point in the conversation with people. There's a kind of a give and take of trying to build intimacy without the moderator putting themselves too much in the conversation or being in any way inappropriate, but also keeping the research participant comfortable. And now we're all looking in one another's bedrooms all the time. We're seeing each other's kids. I'm sure some kid will be wandering in here during this podcast – I can't believe it hasn't happened yet – kids and dogs and whether or not we make our beds in the mornings. So, there's a literal vulnerability. And then, there's an emotional vulnerability that I certainly am seeing in every meeting I'm in, regardless of what we're talking about. There are a few minutes of, how's it going? Oh, you guys just found out that your kids aren't going back to school this year. How's your mom doing? Are you guys seeing her again? Are you guys still saying away from… You know, there's that kind of personal conversation and vulnerability that suggest to me that in a research setting we can get to more meaningful conversation more quickly and understanding what really matters to people is how we make products more successful, right? Supporting those things. So that's kind of my thoughts on design right now. I don't know. I'm curious if you, what your thoughts are too. Jorge: Well, the thought that is on my mind as you are describing that is that it might not be clear to our listeners, because we haven't stated it explicitly, that when we're talking about design, we're talking specifically about the design of software. One of the effects of our response to the pandemic is that we have greatly accelerated the move to doing work and interacting with each other in various ways through software. Audrey: Hmm. Jorge: I wrote a book called Living in Information, and I could not have expected just how literal that would become and how much of our lives would actually be spent living in these information environments in such short term. And I think that their design has become much more pressing and urgent and important as a result of this situation. With that in mind, I'm wondering about the other aspect to the shifting role of design, this notion of the relationship between design as a function of the organization and design as something that organizations bring on board through an external actor like DesignMap. Design as a core competency Audrey: Yeah. So, my perspective is that design is a core competency and a company should always hire internal design teams. So that might sound crazy coming from a consultant, but I really believe that. It's sort of like if you were a software company, but you didn't have any engineers on staff, that would be ridiculous, right? So why would you not have any designers on staff? Design will be happening; it's just a question of who and how much you're paying to do that work and how skilled they are at it. Having said that, I believe that consultants and outside partners will always be useful in the same way that there still exists engineering consultants out there in the world, right? It's sort of impossible to imagine a world, in fact, without vendors that would sell you engineering services. And there's a reason for that. With design in particular, we believe that the pairing can be particularly powerful. So, if you have an internal team and then you have an external partner coming in, those two can work together in a lot of really effective ways. The internal team can provide a glossary, serve as subject matter experts, be guides to whatever political issues there are inside the company, and of course, be part of the team so that when that outside partner goes away, the internal team is better stewards and so the company basically gets better value for the work that they paid for. Because the internal team knows why that decision was made and has some skin in the game on that. Having said that, having a trusted outside partner can help people hire if they've never hired design teams before, as I alluded to earlier. And an external partner can point you to great recruiters, they can be part of the interview team, they can help put together processes and org charts and consult on compensation packages. And if you're actually paying an outside partner to do design work, that makes you a more attractive employer. I believe this with my whole heart. Designers do not want to be the only designer in the whole company. It's a miserable place to be, because you get stuck and there's nobody to turn to you and nobody really understands what you're up against, what's being asked of you, and so saying, we are truly investing in design today, and this is how, and it's now, and its tangible, can make employers more attractive to potential employees. And then of course, having a partner means that sometimes you've got to swallow an elephant, right? Like there's a new product launch. It's not going to always take as much time to design as it takes right now. And I guess another point that's certainly not in the book, but when there's uncertainty and you don't have head count, you don't want to have somebody with benefits on your payroll, because you don't know what's going to happen next quarter, but you need to get something done. They gave you some flexibility. They can level up your team. You know, there's lots of good reasons to do it, which I think apply to pretty much every other job in a software company. It's sort of curious that question is being asked so much of design right now, and I think it's just because maybe two years ago there was such a spate of the consultancies being acquired. That there was this conversation about, oof, you know, it's the end of the era of design consultancies. But again, nobody is saying like, is Accenture going away? Like Accenture's not going away. They're around. So that's kind of my two cents is the best, is a combination that gives you a lot more flexibility and a lot more capability in both kind of tangible and intangible ways, if that makes sense. Jorge: One other argument for. Having this mix of internal and external design teams is that as an external partner, by definition, you're exposed to different problems and different spaces that give you a different set of lenses when approaching a challenge, right? Which is something that you don't get when you're an internal designer focused just on the one organization. Audrey: Yeah. I think that you have two different perspectives, right? When you're internal, you have a deep understanding and you certainly have the perspective of history of what's been tried in the past. An outside partner has the perspective of maybe having tried the same thing at a different company or a similar problem in a totally different space, or the perspective of being totally clueless and really needing to start from the beginning. You know, in a way it's a hallmark of Hugh Dubberly, this like, let's just start from scratch, pretend I don't know anything. And it's not that it needs to necessarily take a long time to ramp up, but to be able to ask the dumb questions and call out opportunities that maybe other folks aren't seeing because you know, their perspective is different, they've been there a long time, you know, that opportunity opened up slowly. It seems obvious to someone new, but it was frog boiling from the inside. And then you combine those two and I think it can be really powerful. I think perspective, by the way, is the most valuable product in the modern world. If you think about like what people pay for, people pay crazy amounts of money for art and therapy, and you know, management consultants, it's all this like magic, which is a fresh perspective, the same information, but a new lens. And I think that's what Hugh does so well. But I also… like if I ever wrote another book, which I won't, so maybe you can write it! I think that this perspective thing is a really… You know, acid trips that help people in hospice expecting to die, they don't have any new information, they just have a new perspective. I think that people will pay any amount of money for that. Jorge: You're reminding me of this quote, I think it's by Alan Kay, where he said something like, point of view is worth 80 IQ points. Audrey: Hmm. Jorge: Right? One of the previous guests in the show, Andrea Mignolo, talked about the role of design in business and design as a way of knowing. You know, not just as a way of making, but as a way of knowing. And the conversation that we were having earlier about research points to this notion that one of the benefits of initiating a design project, like there's this very obvious tangible benefits is like you get a new product or experience or service or what have you out the other end… or an improved one, right? And that's kind of the thing that you're hiring design for, but there's a lot of less tangible benefits that have to do with, “You know, we had to do all this research to get to this point. And that research generated a bunch of new models, which sparked a bunch of insights that maybe lead to the creation of a new product, product line, or a new way of engaging with customers or what have you.” Right? Audrey: Or even just a shared understanding that changes the culture from being adversarial to having a shared goal or understanding. Closing Jorge: It makes a lot of sense, and that strikes me as a really good place for us to wrap the conversation. So where can folks follow up with you? Audrey: Yeah. I would love to hear what people think and chat about this stuff more. They can find me at DesignMap.com. My email address is audrey@designmap.com and pretty much everywhere else I'm audcrane. Or, the book is on Amazon. Jorge: Well, I will link to both in the show notes. So, thank you so much. It's been fabulous catching up with you. Audrey: Yeah. It's been really nice to talk to you too Jorge. I was mentioning before we started recording how lucky I feel to be able to continue to be working and, it's really nice to have people like you to have these conversations with and move things forward, hopefully. Jorge: Feeling is mutual. Thank you so much.
Patricia Jesperson is Chief Curiosity Officer at EmployeeEXP, and co-author of the newly re-released Reversing the Ostrich Approach to Diversity: Pulling your head out of the sand. With more than 25 years working on the people-side of the business, she specializes in working with employers to create better Employee Experience outcomes. As the curious type, Patricia has spent the majority of her career exploring how to maximize the talent experience with an emphasis on Diversity, Equity & Inclusion (DEI) and Total Rewards. This drive for exploring what-ifs enables her to deliver custom content as well as EmployeeEXP proprietary models to help her clients attract, retain, develop and engage talent. Examples include The EmployeeEXP 8 x 9 Box Communication Analysis™, a re-imagined/re-purposed 9-Box that invites organizations to explore their approach to communicating key programs to increasingly diverse talent. It asks the question, “how confident are you that what you spend on Employee Experience is aligned efficiently to attract, retain, and engage today’s diverse talent?” She also introduced The Inclusion Matrix™ (IM) in 2019, which elevates the conversation from traditional DEI training to creating inclusive and engaged leaders. Believing that one must continue to learn to keep current, she seizes opportunities to always-be-learning through teaching at Augsburg University as a professor in the MBA and adult-education programs and her Board experience e.g. Human Resource Executive Forum Board, Augsburg University Alumni Board, Chair of the Workforce Development and Education Policy Committee for the MN Chamber, and Director of Diversity Inclusion for SHRM MN State Council. What you’ll learn about in this episode: How Patricia transitioned her career to working in diversity and inclusion and the people side of business Why Patricia believes that diversity and inclusion practitioners can learn valuable lessons from business development and marketing Why an outcome-based approach to diversity and inclusion can be more effective than a content-based approach How Fortune 500 and 1000 businesses lead the way for diversity and inclusion, and why now mid-market businesses are realizing the need to embrace D&I to compete for talent Why support for a sustainable diverse and inclusive culture needs to be available at all leadership levels of an organization Why human resources and diversity and inclusion shouldn’t be compartmentalized into separate silos but be viewed as a part of an organization’s overall success How Eric S. Raymond’s computer programming essay, The Cathedral & the Bazaar, can teach the value of a faster, more innovative and collaborative process Why organizations often make the mistaken assumption that they have communicated their message clearly and that it is universally understood Additional resources: The Cathedral & the Bazaar by Eric S. Raymond: https://amzn.to/2xnJnsT Reversing the Ostrich Approach to Diversity by Amy Tolbert, Patricia Jesperson, and Alexis Parra: https://amzn.to/2XxDtjH Visit The Forum Podcast, where Patricia Jesperson is an upcoming guest: https://forumworkplaceinclusion.org/podcast/ Website: https://employeeexp.com/ LinkedIn: www.linkedin.com/in/patriciajesperson/
Another open source group "goes woke" as OSI bans founder Eric S. Raymond, Senators attack both encryption AND Section 230 with the EARN IT act, and a court orders Chelsea Manning be released from jail following another suicide attempt. Plus, Biggest Bogon Emitter Jehovah's Witnesses abuse copyright to try and get the personal information of critics and apostates, and the CIA gets Idiot Extraordinaire because of incredibly lax cybersecurity on critical systems.
March 9, 2020 - This is the Bionic Version of the HODLCast Ep. 65 with Jared, originally recorded on February 6, 2019. This was one of my all time favorite podcasts which is why I wanted to revitalize it with this bionic version. Jared is the moderator of R/BitcoinMarkets and the creator of moonmath.win Twitter:@moonmathwin - Jared has an extensive background in open source software development. We discussed the price calculations on the moonmath.win website and surmised what that data means. We also discussed The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary by Eric S. Raymond. It examines the struggle between top-down and bottom-up design, analogous to Ethereum and Bitcoin. You can contact Jared on reddit: https://www.reddit.com/user/jarederaj
YoVirtualizador 1x31 Escritorios 2 Como ya comenté, estoy ampliando el capítulo sobre los escritorios. Hoy con los servidores X desde X11. Un gazapo. El libro es de otra persona https://biblioweb.sindominio.net/telematica/catedral.html Eric S. Raymond YoVirtualizador en formato podcast. Como siempre, podéis localizarme en http://wintablet.info/ y https://yovirtualizador.blogspot.com/ También en Twitter @YoVirtualizador y en Slack https://wintablet.slack.com Grupo de telegram: https://t.me/grupovirtualizador Un saludo. Podcast asociado a la red de SOSPECHOSOS HABITUALES. Suscríbete con este feed: https://feedpress.me/sospechososhabituales
YoVirtualizador 1x31 Escritorios 2 Como ya comenté, estoy ampliando el capítulo sobre los escritorios. Hoy con los servidores X desde X11. Un gazapo. El libro es de otra persona https://biblioweb.sindominio.net/telematica/catedral.html Eric S. Raymond YoVirtualizador en formato podcast. Como siempre, podéis localizarme en http://wintablet.info/ y https://yovirtualizador.blogspot.com/ También en Twitter @YoVirtualizador y en Slack https://wintablet.slack.com Grupo de telegram: https://t.me/grupovirtualizador Un saludo. Podcast asociado a la red de SOSPECHOSOS HABITUALES. Suscríbete con este feed: https://feedpress.me/sospechososhabituales
YoVirtualizador 1x31 Escritorios 2 Como ya comenté, estoy ampliando el capítulo sobre los escritorios. Hoy con los servidores X desde X11. Un gazapo. El libro es de otra persona https://biblioweb.sindominio.net/telematica/catedral.html Eric S. Raymond YoVirtualizador en formato podcast. Como siempre, podéis localizarme en http://wintablet.info/ y https://yovirtualizador.blogspot.com/ También en Twitter @YoVirtualizador y en Slack https://wintablet.slack.com Grupo de telegram: https://t.me/grupovirtualizador Un saludo. Podcast asociado a la red de SOSPECHOSOS HABITUALES. Suscríbete con este feed: https://feedpress.me/sospechososhabituales
February 6, 2019 - Today I had the opportunity to interview JaredRaj, the creator of moonmath.win Twitter:@moonmathwin - Jared moderates the r/bitcoinmarkets and has an extensive background in open source software development. We discussed the price calculations on the moonmath.win website and surmised what that data means. We also discussed The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary by Eric S. Raymond. It examines the struggle between top-down and bottom-up design, analogous to Ethereum and Bitcoin. You can contact Jared on reddit: https://www.reddit.com/user/jarederaj Check out the Transcript of the Podcast here: https://www.sashahodler.com/post/transcript-of-ep-65-moon-math-win
Quincy reads his popular article on how to choose your first programming language when you learn to code. He discusses Python, Java, JavaScript, Ruby, and C++ in terms of: - the job market for the language - the long term prospects for the language - how easy the language is to learn - what projects you can build while you’re learning (and share with friends so you can stay motivated) Read by Quincy Larson (https://twitter.com/ossia) Article link: https://fcc.im/2yCMatt Learn to code for free at: https://www.freecodecamp.org Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q Transcript: Most people’s journey toward learning to program starts with a single late-night Google search. Usually it’s something like “Learn ______” But how do they decide which language to search for? “They always joke about Java on Silicon Valley. I guess I should learn that.” Or: “Haskell. So hot right now. Haskell.” Or: “That Go gopher is just so gosh-darn cute.” And then there’s the rest of us. We’ll probably search for something like: “Which programming language should I learn first?” Few questions are so commonly asked that they get the full infographic treatment. But this is one of them: Deciding on your first programming language can be a fun process — kind of like one of those “Which Quentin Tarantino character are you?” personality quizzes. But before you run off to learn Ruby because you enjoyed playing with Play-Doh as a kid, let me remind you: the stakes are pretty high here. It will take you hundreds of hours of practice to become even remotely competent with your first programming language. So you should consider the following factors: - the job market for the language - the long term prospects for the language - how easy the language is to learn - what projects you can build while you’re learning (and share with friends so you can stay motivated) Every year brings new programming languages, and with them, new academic papers. And new web comics. Seriously. Check out this gem from last month: When it comes to choosing a first programming language, there’s no shortage of options. To narrow it down a bit, here are the most common Google searches related to learning programming, over the past 12 years: Java has had its ups and downs. Python has gradually risen to become the most popular choice. But tucked away below these is the Little Engine That Could, slowly choo-choo’ing up in popularity over the past few years. And that engine is JavaScript. Before I talk about these programming languages, let me clarify: I’m not arguing that any one language is objectively better than any other I agree that developers should eventually learn more than one language I’m arguing that first they should learn one language well. And — as you can probably guess from the upside down text in my headline — that language should be JavaScript. Let’s kick things off by exploring how programming is currently taught in school. Computer Science 101 Universities have traditionally taught programming under the umbrella of computer science, which itself is often seen as an extension of mathematics, or tie-in to an electrical engineering degree. Of course, as you may have heard by now: “Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter.” — Eric S. Raymond As of 2016, many universities still treat programming like it’s computer science, and computer science like it’s math. As a result, many introductory programming courses focus on low-level-of-abstraction languages like C, or mathematically-focused languages like MATLAB. And department chairs generally stay the course, pointing to annual programming language leaderboards like the TIOBE Index, or this one from the IEEE: Most of these leaderboards look virtually identical to how they were 10 years ago. But change does happen. Even in academia. In 2014, Python overtook Java as a the most popular language of instruction at top US Computer Science programs. And yet another change is bound to… eventually… happen. Because if you look at the languages actually used by the workforce, it paints a very different picture: JavaScript is by far the most popular language used by the 49,397 developers who responded to Stack Overflow’s 2016 Survey. More than half of all developers use JavaScript. It’s vital to front-end web development and increasingly relevant for back-end development. And it’s rapidly expanding into areas like game development and the Internet of Things. Job postings also mention JavaScript more than any programming language other than Java: Data from the world’s largest job posting aggregator, Indeed.com It’s no accident that we built our open source community’s curriculum around JavaScript. Over the past two years, more than 5,000 people have used Free Code Camp to get their first developer job. I’m not advocating JavaScript because I teach it. I teach JavaScript because it’s the surest path to a first developer job. But is JavaScript right for you? Is it worthy of being your first programming language? Let’s explore those factors I mentioned earlier. Factor #1: The job market If you’re learning to program purely out of intellectual curiosity, feel free to skip this factor. But if you — like the vast majority of people learning to program — want to use this skill to get a job, this is an important consideration. As I mentioned earlier, Java is mentioned in more job postings than any other programming language. JavaScript is a close second. But here’s the thing about JavaScript: even though it’s been around for 20 years, it only recently became a serious tool that companies like Netflix, Walmart, and PayPal would build entire applications around. As a result, plenty of companies are hiring JavaScript developers, but there just aren’t that many on the job market. There are 2.7 Java developers competing for every open Java position. Competition for PHP and iOS jobs is similarly fierce. But for every open JavaScript position, there are only 0.6 JavaScript developers. It is very much a sellers’ market for developers with JavaScript skills. Factor #2: The long term prospects The average JavaScript project receives twice as many pull requests as the average Java, Python, or Ruby project. And on top of this, JavaScript is growing faster than any other popular language. Source: The GitHub’s 2016 State of the Octoverse JavaScript’s ecosystem also benefits from a heavy investment of money and engineering talent from companies like Google, Microsoft, Facebook, and Netflix. For example, TypeScript (a statically-typed superset of JavaScript) has more than 100 open source contributors, many of whom are Microsoft and Google employees being paid to work on it. This type of inter-company cooperation is harder to find with Java. Oracle — who effectively owns Java through its acquisition of Sun Microsystems — often sues companies who try to expand upon it. Factor #3: Difficulty to learn This is a parody of an XKCD comic. Most programmers would agree that high-level scripting languages are relatively easy to learn. JavaScript falls into this category, along with Python and Ruby. Even though universities still teach languages like Java and C++ as first languages, they’re considerably harder to learn. Factor #4: Projects you can build with it This is where JavaScript really shines. JavaScript runs on any device that has a browser, right there in the browser. You can build basically anything with JavaScript, and share it anywhere. Because of JavaScript’s ubiquity, Stack Overflow co-founder Jeff Atwood coined his now-famous law: “Any application that can be written in JavaScript, will eventually be written in JavaScript.” And with each passing month, Atwood’s Law holds strong. Java once promised to run everywhere, too. You may remember Java Applets. Oracle officially killed them off earlier this year. Python suffers from much the same problems: “How can I give this game I made to my friend? Even better, is there a way can I put this on my phone so I can show it to kids at school without them having to install it? Um.” — James Hague in Retiring Python as a Teaching Language By contrast, here are some apps that members of our open source community built in their browsers on CodePen. You can click through and use these right in your browser: - 1970s style Simon game - Conway’s Game of Life - Star Wars-themed Wikipedia Search - A roguelike dungeon crawler game Learn one language well. Then learn a second one. If you keep jumping from language to language, you won’t get far. In order to move beyond the basics, you need to learn your first language well. Then your second language will be much, much easier. From there, you can branch out, and become a more well-rounded developer by learning lots of languages: C is a great way to learn how computers actually work in terms of memory management, and is useful in high-performance computing C++ is great for game development. Python is awesome for science and statistics. Java is important if you want to work at large tech companies. But learn JavaScript first. OK, now I’m going to attempt the impossible — I’m going to try and anticipate objections from the comments section. Objection #1: But isn’t JavaScript slow? JavaScript is — for most practical purposes — as fast as high-performance languages. JavaScript (Node.js) is orders of magnitude faster than Python, Ruby, and PHP. It is also nearly as fast as high-performance languages like C++, Java, and Go. Here are the results of the most comprehensive recent cross-language benchmark: Objection #2: But JavaScript isn’t statically typed Like Python and Ruby, JavaScript is dynamically typed, which is convenient. But you can get into trouble. Here I intend for exampleArray to be an array. I set its values, then check its length — meaning the number of elements it contains. exampleArray = [1, 2] -> [1, 2] exampleArray.length -> 2 But then I accidentally assign it to be a string. exampleArray = “text” -> “text” exampleArray.length -> 4 These kinds of errors happen all the time in dynamically typed languages. Most developers just put checks in place to prevent them, and write tests accordingly. If you absolutely must have static typing in your first programming language, then I still recommend you learn JavaScript first. Then you can quickly pick up TypeScript. “Typescript has a learning curve, but if you already know JavaScript, it will be a smooth one.” — Alex Ewerlöf on TypeScript Objection #3: But I really want to make a mobile app I still recommend learning JavaScript first. JavaScript features several tools for making native mobile apps, such as Angular Cordova and React Native. In order for your mobile app to actually do anything interesting, it will probably need a proper back end, which you’ll want to build with a proper web development framework, like Node.js + Express.js. Also, it’s worth pointing out that the mobile app development’s best days may very well be behind it. For starters, as much as people use mobile apps, nearly half of all developer jobs are web development. Compare this with a mere 8% of jobs that involve mobile app development. The occupations of 49,525 developers, based on responses to the 2016 Stack Overflow survey. The grand vision of “there’s an app for that” has not come to pass. Instead, most smartphone owners have stopped downloading new apps. Sure — they still use apps. Mostly Facebook, Google Maps, and handful of others. As such, much of the demand for mobile app developers is concentrated in a few large employers. The outlook for those mobile development jobs is hard to forecast. Many aspects of developing, maintaining, and distributing mobile apps are easier with JavaScript. So companies like Facebook and Google are investing heavily in better tools for building these using JavaScript. As of 2016, pretty much all development is web development. Everything touches that big platform that is “the web.” And the next wave of devices that you’ll talk to around your home, and cars that pick your kids up from school — they’ll all be piped together using the web, too. And that means JavaScript. Objection #4: Isn’t JavaScript a toy language that was written in 10 days? JavaScript has a quirky history. You will undoubtedly hear people crack jokes at its expense. Well people love to hate on C++, too. And like JavaScript, C++ has succeeded despite this hate, and now it’s pretty much everywhere as well. So if anybody ever gives you a hard time for learning JavaScript instead of elite-language-of-the-week, just remember the famous words of the guy who created C++: "There are only two kinds of programming languages: those people always bitch about and those nobody uses." — Bjarne Stroustrup
Wave, 1891. Bibliothèque de Toulouse Erik and Potatowire talk about trying to keep your head above water on the internet, what makes a good biography, the corrupting lens of the present moment and the written word, what happens when the incomprehensible talks back, and building a doghouse from first principles. Robert Caro Robert Caro - The Years of Lyndon Johnson Robert Caro - The Power Broker William Manchester - The Last Lion Hindsight Bias Douglas Hofstadter Douglas Hofstadter - Surfaces and Essences Douglas Hofstadter - Gödel, Escher, Bach Douglas Hofstadter - I Am a Strange Loop Douglas Hofstadter - The Mind’s I Jeff VanderMeer - Southern Reach Trilogy Neal Stephenson - Snow Crash Nassim Nicholas Taleb - Fooled by Randomness Nassim Nicholas Taleb - Antifragile Nassim Nicholas Taleb - Black Swan Stanislaw Lem - Solaris Arkady and Boris Strugatsky - Roadside Picnic Eric S. Raymond - The Cathedral & The Bazaar
Interview with Eric S. Raymond.File info: 8MB, 17 minutes.
Panel Manton Reece (twitter github blog) Ben Scheirman (twitter github blog NSSreencast) Pete Hodgson (twitter github blog) Andrew Madsen (twitter github blog) Jaim Zuber (twitter Sharp Five Software) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:13 - Manton Reece Introduction VitalSource Riverfold Software 01:33 - Subscription APIs and Recurring Revenue 02:25 - How Subscriptions Work 12:10 - In-app Purchases Non-renewing Subscriptions Auto Renewing Subscriptions 16:11 - Verifying Receipts Store Kit 19:32 - Subscription Levels Changing Plans 25:14 - Payments Stripe vs PayPal Picks Eric S. Raymond: The Lost Art of C Structure Packing (Jaim) Torchlight II (Ben) SC2Casts (Ben) after_party (Ben) thebennybox (Ben) Using Receipts to Protect Your Digital Sales (Ben) Using Store Kit for In-App Purchases (Ben) 2 Free (Technical Support Incidents) TSIs (Pete) Bay Area Casual Carpool (Pete) Bay Area Bike Share (Pete) Lucky 13 (Pete) Mike Ash: Friday Q&A 2014-01-10: Let's Break Cocoa (Andrew) The official raywenderlich.com Objective-C style guide (Andrew) Bacon Ipsum (Chuck) David Brady: The Job Hunting Mindset (Chuck) David Brady: The Job Replacement Guide: Why I Have To Write This Book (Chuck) Stripe (Manton) Helios (Manton) Next Week MGPCommandBus with Saul Mora Transcript CHUCK: We got this Man-ton on our show! CHUCK: Hey everybody and welcome to episode 39 of the iPhreaks Show. This week on our panel we have Ben Scheirman. BEN: Hello, from Bayou City. CHUCK: Bayou City? BEN: That's Houston's nickname. If we had a Ruby Conference, it would be Bayou City Ruby, and no one would know where it was. CHUCK: Yeah, that's true. ANDREW: We'd all be in Louisiana. [Chuckling] CHUCK: Why are y'all in New Orleans? JAIM: That would be dirty south [inaudible]. CHUCK: Hey, at least you can go [inaudible]. Anyway –. JAIM: No offense to my New Orleans listeners. CHUCK: [Chuckles] We also have Pete Hodgson. PETE: Good morning from San Francisco! I don't know what her nickname is; I should look that up. JAIM: Golden Gate City, is that it? PETE: I was tempted to go for Rainbow City, but –. CHUCK: [Laughs] We're batting two for two this morning. Alright, Andrew Madsen. ANDREW: Hi from Salt Lake City. CHUCK: Jaim Zuber. JAIM: Hello from the Twin Cities. CHUCK: I'm Charles Max Wood from DevChat.tv and this week we have a special guest, and that is Manton Reece. MANTON: Hello from Austin, Texas! Good to be here. CHUCK: Hey, I managed to say that right! Do you wanna introduce yourself for those of us who don't know who you are? MANTON: Sure. My name is Manton Reece, and I work for a company called VitalSource doing e-book software with Mac iOS12 web development, and I have a little side business called Riverfold Software where I have a number of iOS and Mac apps, web apps. CHUCK: Cool! So we brought you on today to talk about subscription APIs and recurring revenue – is that a thing for iOS? MANTON: That's a thing for iOS. It depends who you ask what kind of answer you're gonna get about the right way to do that, or whether you should do it. But it's a thing, I would say. CHUCK: I thought the thing was to write Angry Birds and make millions of dollars. MANTON: That's one way to do it. The problem with the app store – the great thing and the problem is that you do have these huge hits that make way too much money, but then most of us aren't that lucky, and even the ones that are lucky have a big hit, you sell a bunch of copies, you quit your job, you say, “This is great” and you do really well. Eventually, your app's gonna fall out of the top 10 and top 100 and sales are gonna drop off and so you have to do it all over again and get a big launch. So, the subscriptions, the hope is you get a little more recurring revenue,
Panel Manton Reece (twitter github blog) Ben Scheirman (twitter github blog NSSreencast) Pete Hodgson (twitter github blog) Andrew Madsen (twitter github blog) Jaim Zuber (twitter Sharp Five Software) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:13 - Manton Reece Introduction VitalSource Riverfold Software 01:33 - Subscription APIs and Recurring Revenue 02:25 - How Subscriptions Work 12:10 - In-app Purchases Non-renewing Subscriptions Auto Renewing Subscriptions 16:11 - Verifying Receipts Store Kit 19:32 - Subscription Levels Changing Plans 25:14 - Payments Stripe vs PayPal Picks Eric S. Raymond: The Lost Art of C Structure Packing (Jaim) Torchlight II (Ben) SC2Casts (Ben) after_party (Ben) thebennybox (Ben) Using Receipts to Protect Your Digital Sales (Ben) Using Store Kit for In-App Purchases (Ben) 2 Free (Technical Support Incidents) TSIs (Pete) Bay Area Casual Carpool (Pete) Bay Area Bike Share (Pete) Lucky 13 (Pete) Mike Ash: Friday Q&A 2014-01-10: Let's Break Cocoa (Andrew) The official raywenderlich.com Objective-C style guide (Andrew) Bacon Ipsum (Chuck) David Brady: The Job Hunting Mindset (Chuck) David Brady: The Job Replacement Guide: Why I Have To Write This Book (Chuck) Stripe (Manton) Helios (Manton) Next Week MGPCommandBus with Saul Mora Transcript CHUCK: We got this Man-ton on our show! CHUCK: Hey everybody and welcome to episode 39 of the iPhreaks Show. This week on our panel we have Ben Scheirman. BEN: Hello, from Bayou City. CHUCK: Bayou City? BEN: That’s Houston’s nickname. If we had a Ruby Conference, it would be Bayou City Ruby, and no one would know where it was. CHUCK: Yeah, that’s true. ANDREW: We’d all be in Louisiana. [Chuckling] CHUCK: Why are y’all in New Orleans? JAIM: That would be dirty south [inaudible]. CHUCK: Hey, at least you can go [inaudible]. Anyway –. JAIM: No offense to my New Orleans listeners. CHUCK: [Chuckles] We also have Pete Hodgson. PETE: Good morning from San Francisco! I don’t know what her nickname is; I should look that up. JAIM: Golden Gate City, is that it? PETE: I was tempted to go for Rainbow City, but –. CHUCK: [Laughs] We’re batting two for two this morning. Alright, Andrew Madsen. ANDREW: Hi from Salt Lake City. CHUCK: Jaim Zuber. JAIM: Hello from the Twin Cities. CHUCK: I'm Charles Max Wood from DevChat.tv and this week we have a special guest, and that is Manton Reece. MANTON: Hello from Austin, Texas! Good to be here. CHUCK: Hey, I managed to say that right! Do you wanna introduce yourself for those of us who don’t know who you are? MANTON: Sure. My name is Manton Reece, and I work for a company called VitalSource doing e-book software with Mac iOS12 web development, and I have a little side business called Riverfold Software where I have a number of iOS and Mac apps, web apps. CHUCK: Cool! So we brought you on today to talk about subscription APIs and recurring revenue – is that a thing for iOS? MANTON: That’s a thing for iOS. It depends who you ask what kind of answer you're gonna get about the right way to do that, or whether you should do it. But it’s a thing, I would say. CHUCK: I thought the thing was to write Angry Birds and make millions of dollars. MANTON: That’s one way to do it. The problem with the app store – the great thing and the problem is that you do have these huge hits that make way too much money, but then most of us aren’t that lucky, and even the ones that are lucky have a big hit, you sell a bunch of copies, you quit your job, you say, “This is great” and you do really well. Eventually, your app’s gonna fall out of the top 10 and top 100 and sales are gonna drop off and so you have to do it all over again and get a big launch. So, the subscriptions, the hope is you get a little more recurring revenue,
In this episode we talk to Campbell Barton from the Blender Foundation about how they were able to migrate from a very complicated SVN setup to Git. If you cannot see the audio controls, your browser does not support the audio element. Use the link below to download the mp3 manually. Link to mp3Links:The Blender foundationBlender's migration using reposurgeon:Reposurgeon, developed by Eric S. Raymond and Julien RivaudHow reposurgeon wins (features, compares with other tools)Main Blender migration repositoryBlender migration readmeBlender addons - good example of a small repoThe git submodule issue we ran intoBlender's new issue/patch tracker:Phabricator (issue tracker from Facebook)Phabricator Arcanist (command line tool)Blender's Phabricator instance"Famous" Git migrations/inspiration:A tale about a Big SVN to Git Migration (JBoss Tools) (slides)Converting a Subversion repository to Git (Drupal) Migrating from Subversion to GitGnome's Git migrationKDE's move to GitQT switching to Git (part 1)QT switching to Git (part 2)Battle of Wesnoth switching to Git (using reposurgeon)Get in touch with Campbell/Blender:The Blender NetworkBlender Stack ExchangeYou can reach Campbell via email on ideasman42 [at] gmail.comThe Blender PodcastThis week's pro-tip:List all files ever:git log --all --pretty=format: --name-only --diff-filter=A | sort --unique -See the Blender migration readme for more handy one-liners.Listen to the episode on YouTube
Jason Fried co-founded 37signals, a Web design company that found one of its internal tools for managing projects could be something effectively used by others. Millions of users later, 37signals offers Basecamp (overhauled substantially a year ago), Campfire, and Highrise among other services. The founders not only transformed their business, but routinely help others transform theirs. Fried collaborated on a book called Rework that distills years of what he learned from running a successful company and helping others with theirs. You can look at and sign up for Basecamp as a trial subscription, but this episode isn't a product plug; Basecamp fits the disruption mindset. Microsoft Project is perfectly fine software for companies that have employees in one place and need the top-down approach. Software as a service (SaaS) typically involves an application you access via the Web for which data is stored centrally, and updates to the software happen centrally as well. Salesforce, an early SaaS alternative to enterprise-licensed and -managed software, was founded in 1999, and had risen as a force that defined the industry by the time Basecamp came out. Rework may be purchased from Amazon.com and many other fine bookstores. Glenn brought up three concepts relating to 37signals' work: The Cathedral and the Bazaar, Eric S. Raymond's explanation of the difference between software code controlled by a handful of priests and that in the marketplace that's open to all; The Cluetrain Manifesto, a provocative set of theses that turned into a revolution and a book by declaring, among other things, that markets are conversations; and Stephen Jay Gould's use of the term hecatomb to explain evolution's remorseless pruning of failed mutations.
Prometheus Unbound Podcast: Libertarians Talking About Science Fiction and Fantasy
In a new addition to the Mises Institute's online media library today, part of The Libertarian Tradition podcast series, Jeff Riggenbach discusses libertarian science fiction. Riggenbach discusses the role of science fiction in keeping individualism alive, the phenomenon of all the best known libertarian novels being science fiction novels, Eric S. Raymond's "A Political History of SF" in which Raymond argues that science fiction has a natural affinity with libertarianism, and the importance of dramatizing our values (pdf).
© 2020-2025 Ivy Podcast Discovery LLC
