Podcasts about sourcetree

#130. Sprint 1 is a magical, wonderful, beautiful thing. Find out how my messy, unstructured and un-estimated sprint 1 unfurled on a recent project to build a Power Platform app for a mid-size Microsoft customer in financial services.In-person conferences I didn't attend:Power Platform ConferenceNordic SummitSouth Coast SummitUpcoming online conferences I'm presenting at:2 Nov 2022 at Power Platform 244 Nov 2022 at New Zealand Business Applications SummitLearn how to qualify, pitch, propose and close more agile projects:Winning Agile ProjectsTools we're using in sprint one:Miro for visual collaborationAtlassian Confluence for wiki pagesAtlassian Bitbucket and Sourcetree for source controlAzure DevOps for backlog, boards and pipelinesSlack for chatZoom for meetingsSharePoint for file sharingCopy.ai for AI-assisted creative copywritingSupport the show

It's raining cats and dogs – подкаст в якому інженери MacPaw обговорюють новини, роботу та теми, які нас хвилюють. Такі собі затишні балачки поки за вікном злива ;) Роман Тищенко — https://www.linkedin.com/in/roman-tyshchenko-1b937035/ Сергій Кривоблоцький – https://twitter.com/Krivoblotsky Євгеній Петелєв – https://twitter.com/peteliev 00:00 Вcтуп 00:29 Вітаємося Коментар уважного слухача 00:49 10 десктопів чи 3 монітори? 7:35 Mac не треба, давайте Asus Новина місяця 9:25 Apple Event: Перший нішевий продукт 11:42 Dynamic island 14:28 А навіщо мені новий iPhone? 15:33 Нові Apple Watch і фокус на безпеку 17:22 Широка лінійка девайсів викликає паніку? 18:10 Чи краще нішеві девайси Apple, ніж конкуренти? 20:02 Тенденція все оновлювати 21:11 Як нова iOS? 22:53 Які апки Apple вбив цього разу? 24:43 Оновлення CarPlay 33:56 Adobe купив Figma 40:16 Вікторини — хто кого й за скільки кого купив? 50:50 Як Uber взламали Tool місяця 55:44 Light Phone та його функціонал  1:04:40 Тренд на спрощення 1:08:52 Віджети — використовувати чи ні? 1:13:33 GitHub Desktop, Xcode, Sourcetree 1:17:21 Тули для селф-менеджменту 1:19:41 Як тримати фокус на тасках і не відволікатися? А що там по роботі? 1:23:16 Конференція від JNUC. Пошук додатків за територіальною приналежністю 1:24:27 iOS 16, macOS 13 — баги і удосконалення 1:29:26 Старт стажування у MacPaw 1:31:28 Курси чи стажування? 1:37:08 Як проводити і проходити співбесіду? 1:40:34 Мораль Facebook: https://www.facebook.com/macpawtechtalks Telegram: https://t.me/mtechtalks

In deze aflevering bespreken we het einde van IE 11, nieuwe updates in Safari 16, is neumorphism dood, het zwitsers zakmes genaamd Visual Studio Code, een mega handig plugin voor AI, EPS en PDF bestanden voor Figma en nog veel meer! 1:27- Internet Explorer 11 is End of Life

Git und Sourcetree mit Gitlab oder Github - Kollaboratives Arbeiten als Data Scientist oder Analyst

DITA w modelu "docs as code"? Kto to widział? Czy to się da zrobić i czy to w ogóle ma sens? Po snuciu teorii na ten temat, przyszedł czas na konkretne działania. Rozmawiamy o tym co do tej pory udało nam się zrobić, żeby w naszej organizacji wdrożyć "DITA as code". Mówimy o narzędziach, przykładowym procesie robienia zmian w dokumentacji, napotkanych trudnościach i kolejnych krokach. Jeśli "DITA z gita" jest bliska Waszemu sercu to zapraszamy do odsłuchu. Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0. Informacje dodatkowe: "#16 DITA z Gita", Tech Writer koduje: https://techwriterkoduje.pl/blog/2020/04/22/dita-z-gita "#8 DITA OT - static site generator dla wtajemniczonych", Tech Writer koduje: https://techwriterkoduje.pl/blog/2019/09/28/dita-ot Standard DITA (Darwin Information Typing Architecture): https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture Component Content Management System (CCMS): https://en.m.wikipedia.org/wiki/Component_content_management_system Git: https://git-scm.com/ "Docs as code", Write the Docs: https://www.writethedocs.org/guide/docs-as-code/ Bitbucket: https://bitbucket.org/ Git submodules: https://www.atlassian.com/git/tutorials/git-submodule Bitbucket pull requests: https://www.atlassian.com/git/tutorials/making-a-pull-request Oxygen XML: https://www.oxygenxml.com/#bidx-xml-author "Krytyczna podatność w bibliotece Apache Log4j": https://cert.pl/posts/2021/12/krytyczna-podatnosc-w-bibliotece-apache-log4j/ Sourcetree: https://www.sourcetreeapp.com/ DITA Open Toolkit (DITA OT): https://www.dita-ot.org/ Docker: https://www.docker.com/ Amazon Simple Storage Service (S3): https://aws.amazon.com/s3/ TeamCity: https://www.jetbrains.com/teamcity Schematron: https://www.schematron.com/ "Content Reuse": https://paligo.net/docs/en/content-reuse.html Git hooks: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks "Readability – what is it and how do I improve it?", Paweł Kowaluk (soap! 2018): https://www.youtube.com/watch?v=LzrHrIOHhz8

Show Notes:- Join our Slack Workspace! https://join.slack.com/t/firesideswift/shared_invite/zt-nik3miom-qJ_53_yND4OwV2ZG3Xo4RQ- Joe Cab's Handy Dandy Spreadsheet: http://joecab.link/fireside-episodes- StackOverflow: https://stackoverflow.com- Twitter: https://twitter.com- Charles: https://www.charlesproxy.com- Proxyman: https://proxyman.io- Fork: https://git-fork.com- iPad: Mockup (@MockupApp / @hasankassem_) https://getmockup.app- DevCleaner - Konrad Kołakowski @vashpan: https://apps.apple.com/us/app/devcleaner-for-xcode/id1388020431?mt=12- Sourcetree: https://www.sourcetreeapp.com- VSCode: https://code.visualstudio.com- Putty: https://www.putty.orgYou can reach us on Twitter!All of us: @Fireside_Swift- Steve: @SWBerard- Ben: @MrMcSwiftface- Chris: @Heffertron- Jordan: @JordanNoHandleFireside Swift Theme song by Mike “Golden Pipes” DillinghamBlind Love Dub by Jeris (c) copyright 2017 Licensed under a Creative Commons Attribution (3.0) license. http://dig.ccmixter.org/files/VJ_Memes/55416 Ft: Kara Square (mindmapthat)

As we've become nerdier while learning from Bart, we had started to add hidden configuration files to our Macs and PCs. On the Mac, these configuration files hidden by default by putting a dot in front of them, and hence they are called dot files. Maybe you've stored your ssh keys, or in our Git series you created a user-level gitconfig file, or perhaps you've installed VS Code or Sourcetree which also add hidden configuration files. In this installment of Programming By Stealth, Bart explains the problem to be solved of how we manage these configuration files if we use multiple computers or migrate to a new computer or do a nuke and pave. He lays the groundwork for why he loves the dot file manager called Chezmoi from chezmoi.io. The installment is a bit of a tease because after learning why we want to have a dot file management tool and why Bart favors Chezmoi for the job, he only lets us install it and run two commands before he says, "And next time we'll start to use Chezmoi."

As we've become nerdier while learning from Bart, we had started to add hidden configuration files to our Macs and PCs. On the Mac, these configuration files hidden by default by putting a dot in front of them, and hence they are called dot files. Maybe you've stored your ssh keys, or in our Git series you created a user-level gitconfig file, or perhaps you've installed VS Code or Sourcetree which also add hidden configuration files. In this installment of Programming By Stealth, Bart explains the problem to be solved of how we manage these configuration files if we use multiple computers or migrate to a new computer or do a nuke and pave. He lays the groundwork for why he loves the dot file manager called Chezmoi from chezmoi.io. The installment is a bit of a tease because after learning why we want to have a dot file management tool and why Bart favors Chezmoi for the job, he only lets us install it and run two commands before he says, "And next time we'll start to use Chezmoi."

Watch the live stream: Watch on YouTube About the show Sponsored by us: Check out the courses over at Talk Python And Brian's book too! Special guest: Jay Miller Michael #1: Autosync all branches of a fork Use GitHub actions to keep your fork in sync Step 1: make changes in a separate branch (a branch other than main) to keep the working tree clean and avoiding conflicts with upstream Step 2: Add a new workflow under the “actions” section. We are going to follow the Fork-Sync-With-Upstream-action from the Actions Marketplace. Copy the YAML in the article being careful to use the right repo/branch names Step 3: click on Start Commit and Commit new file and that's it! See your running workflow in the actions tab Brain #2: Measuring memory usage in Python: it's tricky! Itamar Turner-Trauring Nice, easy to follow discussion of memory Cool example to allocate 3 GB arr = np.ones((1024, 1024, 1024, 3), dtype=np.uint8) that's a 4 dimensional array of bytes, 1k x 1k x 1k x 3 “Resident Memory” measured with psutil.Process().memory_info().rss rss = “Resident Set Size”, or “non-swapped physical memory” returns bytes, so / (1024 * 1024) gives MB Shows a little more than 3 GB Doing nothing to process, but opening a few tabs in a browser and re-running rss shows a reduction due to some memory being saved to disk. Fil profiler can show peak allocated memory. Memory Resident Memory : RAM usage Allocated Memory : what we asked for, not really measurable Peak Allocated Memory : kinda the same, but not, and it's measurable Tradeoffs between measuring the two Jay #3: Python f-strings can do more than you thought. f'{val=}', f'{val!r}', f'{dt:%Y-%m-%d}' Caution! Just because you can doesn't mean you should but sometimes you will be looking for a way to do something Michael #4: 10 Tips and Tools You Can Adopt in 15 minutes or Less To Level Up Your Dev Productivity Upgrade your shell (ohmyzsh or ohmyposh) + Windows Terminal with PS 7 Secure.py (or NWebSec for ASP.NET or …) Use a UI for git (SourceTree, GitHub Desktop, PyCharm, VS Code, etc) Sync your github forks Use a good logging framework: Logbook, Loguru, even Sentry SSL/TLS with Let's Encrypt 80/20 testing with sitemaps PageSpeed insights (e.g for Python Bytes) Use an OS package manager: Homebrew, Chocolaty, or Linux's built in) Manage your dependencies with dependabot or even pip-compile requirements.in --upgrade Full conference video Brian #5: How to Start a Production-Ready Django Project Vitor Freitas Some great points for really any project, not just Django projects Make sure different environments work with the project, in this priority: local, so clone and run is easy and new people can onboard fast test, also local, so devs actually test with no issues production, can be more complicated since only experienced people will need it, or it will get run by your CI/CD chain production is also used in staging Configure git and venv from the beginning. Cool requirements files example with a requirements directory containing base.txt test.txt : base.txt + test stuff local.txt : test.txt + dev stuff production.txt : base.txt + any production only stuff Settings setup, also with switched implementation for local, test, prod Shared editor configuration, interesting addition Shared linting and styling tools, isort, black, flake8, … There are some Django specifics also, like app structure. Jay #6: Bunch macOS application that allows you to create starting and finishing workflows How Jay sets up and tears down the newsletter video Extras Jay Monodraw - Make diagrams or outlines using ascii art Joke

This week in our miniseries on learning the version control system Git, Bart dips our proverbial toe into branching. Branches allow us, as developers, to work on bugs or feature enhancements in a separate place from our stable code, and only merge the code back in when the bugs are squashed or the features are stable. We don't get much practice in this instalment, but rather Bart talks to us about the idea of having a strategy for when to branch and how to name your branches in order to prevent chaos. He gives us some simple and yet difficult to adhere to strategies and then takes us through more rigorous strategies that will actually be easier to follow. He emphasizes that he's not telling us which strategy to follow, but rather to have a strategy. We do a few small examples from the command line, but we get to open our Git GUI clients, like GitKraken and Sourcetree and see how the commands we're typing are graphically represented in the clients. It's a good illustration of what Bart has been promising us – that the GUI clients are doing exactly what the command line is doing. You can find Bart's tutorial shownotes at https://pbs.bartificer.net/pbs107. And if you'd like to support Bart on Patreon, go to patreon.com/ltpod.

This week in our miniseries on learning the version control system Git, Bart dips our proverbial toe into branching. Branches allow us, as developers, to work on bugs or feature enhancements in a separate place from our stable code, and only merge the code back in when the bugs are squashed or the features are stable. We don't get much practice in this instalment, but rather Bart talks to us about the idea of having a strategy for when to branch and how to name your branches in order to prevent chaos. He gives us some simple and yet difficult to adhere to strategies and then takes us through more rigorous strategies that will actually be easier to follow. He emphasizes that he's not telling us which strategy to follow, but rather to have a strategy. We do a few small examples from the command line, but we get to open our Git GUI clients, like GitKraken and Sourcetree and see how the commands we're typing are graphically represented in the clients. It's a good illustration of what Bart has been promising us – that the GUI clients are doing exactly what the command line is doing. You can find Bart's tutorial shownotes at https://pbs.bartificer.net/pbs107. And if you'd like to support Bart on Patreon, go to patreon.com/ltpod.

Dedicamos este episodio a hablar sobre los repositorios Git en la nube, espacios que nos permiten mantener una versión de nuestro código, trabajar de manera colaborativa, ejecutar tests y también realizar despliegues y otras mágicas funcionalidades. Empezamos el episodio tratando sobre en qué consiste un repositorio de código y cómo Git se ha convertido en el estándar a la hora de pensar en control de versiones. Centramos la conversación sobre los dos proveedores más importantes: GitHub y GitLab. El primero está considerado como la red social del código y tras su adquisición por parte de Microsoft está incorporando multitud de funcionalidades en su capa gratuita. Por su parte, GitLab es una soberbia plataforma de código abierto, dirigida a ser la solución integral para DevOps y una aplicación de Integración y Desarrollo Continuo para proyectos de software. Entre las cuestiones que tratamos en el episodio, tenemos: - Sistema de control de versiones Git y su uso local. - Diferencias esenciales entre GitHub y GitLab. - Clientes GUI: Github Desktop, Gitkraken, SourceTree, Git GUI, Tower, Lazygit, Sublime merge - Integración con IDE’s: Atom, Brackets, Jetbrains (integración con GitHub, Git), VSCode. ¡Contribuye a este podcast!. A través de la plataforma Buy me a coffee puedes realizar una mínima aportación desde 3€ que ayude a sostener a este podcast. Tú eliges el importe y si deseas un pago único o recurrente. ¡Muchas gracias! Sitio web de Javier Archeni: https://javierarcheni.com Sitio web de Andros Fenollosa https://programadorwebvalencia.com Sitio web de David Vaquero https://cursosdedesarrollo.com

Dedicamos este episodio a hablar sobre los repositorios Git en la nube, espacios que nos permiten mantener una versión de nuestro código, trabajar de manera colaborativa, ejecutar tests y también realizar despliegues y otras mágicas funcionalidades. Empezamos el episodio tratando sobre en qué consiste un repositorio de código y cómo Git se ha convertido en el estándar a la hora de pensar en control de versiones. Centramos la conversación sobre los dos proveedores más importantes: GitHub y GitLab. El primero está considerado como la red social del código y tras su adquisición por parte de Microsoft está incorporando multitud de funcionalidades en su capa gratuita. Por su parte, GitLab es una soberbia plataforma de código abierto, dirigida a ser la solución integral para DevOps y una aplicación de Integración y Desarrollo Continuo para proyectos de software. Entre las cuestiones que tratamos en el episodio, tenemos: - Sistema de control de versiones Git y su uso local. - Diferencias esenciales entre GitHub y GitLab. - Clientes GUI: Github Desktop, Gitkraken, SourceTree, Git GUI, Tower, Lazygit, Sublime merge - Integración con IDE’s: Atom, Brackets, Jetbrains (integración con GitHub, Git), VSCode. ¡Contribuye a este podcast!. A través de la plataforma Buy me a coffee puedes realizar una mínima aportación desde 3€ que ayude a sostener a este podcast. Tú eliges el importe y si deseas un pago único o recurrente. ¡Muchas gracias! Sitio web de Javier Archeni: https://javierarcheni.com Sitio web de Andros Fenollosa https://programadorwebvalencia.com Sitio web de David Vaquero https://cursosdedesarrollo.com

In this episode of the iPhreaks Show the panel introduces themselves and discusses their favorite tools and what their builds look like. They share their journeys in iOS development and their experiences in large teams compared to smaller teams. They consider how iOS has changed since they first started iOS development.  The panel discusses what CI/CD’s they are using. They discuss, Xcode, VScode and the Dash app. They move on to testing, explaining that they generally use what apple provides unless they need something that digs a little deeper. They discuss Fastlane as a deployment tool. Tools they use for crash reports include Sentry, Xcode, and Crashlytics. For debugging the panel discusses Reveal, Sourcetree, SwiftLint, Charles proxy, and Pony debugger. Charles wonders what they prefer for their backend. Alex Bush explains that it depends on the size of the company. Larger companies prefer custom-built backends. They consider Ruby on Rails, Realm, and Runscope for smaller companies. Panelists Alex Bush Charles Max Wood Christina Moulton Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan CacheFly Links https://revealapp.com/ https://kapeli.com/dash https://www.sourcetreeapp.com/ https://www.sharemouse.com/ https://www.charlesproxy.com/ https://www.facebook.com/iphreaks/ https://twitter.com/iphreaks Picks Christina Moulton: Finding slow code with Instruments Charles Max Wood: Disney+ Frozen 2

In this episode of the iPhreaks Show the panel introduces themselves and discusses their favorite tools and what their builds look like. They share their journeys in iOS development and their experiences in large teams compared to smaller teams. They consider how iOS has changed since they first started iOS development.  The panel discusses what CI/CD’s they are using. They discuss, Xcode, VScode and the Dash app. They move on to testing, explaining that they generally use what apple provides unless they need something that digs a little deeper. They discuss Fastlane as a deployment tool. Tools they use for crash reports include Sentry, Xcode, and Crashlytics. For debugging the panel discusses Reveal, Sourcetree, SwiftLint, Charles proxy, and Pony debugger. Charles wonders what they prefer for their backend. Alex Bush explains that it depends on the size of the company. Larger companies prefer custom-built backends. They consider Ruby on Rails, Realm, and Runscope for smaller companies. Panelists Alex Bush Charles Max Wood Christina Moulton Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan CacheFly Links https://revealapp.com/ https://kapeli.com/dash https://www.sourcetreeapp.com/ https://www.sharemouse.com/ https://www.charlesproxy.com/ https://www.facebook.com/iphreaks/ https://twitter.com/iphreaks Picks Christina Moulton: Finding slow code with Instruments Charles Max Wood: Disney+ Frozen 2

Source control is something everyone should be practicing. Maybe you know the term but not the reasons why it is important. I am going to give you three reasons why you should be using it along with some tool suggestions to get you started. Sourcetree for Mac and Windows Tower - For Mac and Windows Git Bitbucket Github Follow on Twitter: @CompileSwift --- Send in a voice message: https://anchor.fm/compileswift/message Support this podcast: https://anchor.fm/compileswift/support

In this week's episode of the DevEd podcast, the panelists talk on comments in programming. To give a context of the chosen topic, Joe mentions that he sends out regular newsletters to Thinkser.io subscribers related to a variety of concepts, and has recently been sending out some on code smells, in one of which he talks about commenting. He gives an idea of what code smells are, and shares his opinion on using comments. His point of view is that a comment can be looked at as a failure or an inability to express the code functionality or even the technology involved, or is needed to make the code completely readable to other programmers. Comments can become out of date or get replaced. The other panelists join in the discussion on whether comments are good or bad, and they state that for beginners they can be very useful while not so much for experienced programmers. Too many comments can cause a mess, so they ideally should be used for large complex functions. They are mostly used to specify if refactoring is needed at a later stage, they should explain the "why" instead of "how", and in general the code should ideally be self-sufficient. They talk about when do they actually like to use comments. If a certain piece of code is doing something unusual or non-obvious or might break the consistency with the rest of the code, then it is imperative to explain why it is written that way. It can also be a good idea to document things for new or junior developers in the team in order to explain what is going on or what should not be done, and also to pair program with them in case things are not clear. Commit messages could be a replacement for comments as well. Comments are also useful when static values and constants such as URLs or UIDs are used in the code, and for explaining specific error mechanisms. They share great practical advice for programmers who are in the earlier stages of their software development career and have generally been taught to use comments by their professors or mentors. The tips they give include taking time to look through the codebase, checking how and where comments are being used by other developers, refactoring the code to write more readable functions wherever things are unclear, using good naming conventions, trying to write self-documenting code, asking a lot of questions to whoever has written the code including asking the reasons why it is written a certain way, and not being afraid to add comments of your own. They then discuss some replies to the newsletter sent by Joe about code smells related to the importance of comments in the messy reality of engineering, pros and cons of their usefulness, tradeoff between maintaining self-documented vs heavily documented code. They end the show with picks. The DevEd podcast is produced by Thinkster.io and published by DevChat.TV. Panel Joe Eames Jesse Sanders Luis Hernandez Preston Lamb Mike Dane Sponsors Thinkster.io The Freelancers' Show React Round Up CacheFly Picks Luis Hernandez: Sourcetree Mike Dane: Google Fi Preston Lamb: Office Ladies podcast Jesse Sanders: Tesla cars Joe Eames: Gaslands Question #1: What are code smells? A pattern that indicates that there may be a problem in the code with a possibility of improvement. Question #2: When should comments be used? Comments could be useful for beginners, not so much for experienced folk. Too many comments can cause a mess, so they ideally should be used only for large complex functions. They can be used to specify if refactoring is needed at a later stage, and for explaining the "why" instead of "how". Question #3: What are some good reasons to use comments? 1. If a certain piece of code is doing something unusual/non-obvious/might break the consistency with the rest of the code. 2. For new or junior developers on the team in order to explain what is going on or what should not be done. 3. When using static values and constants. Question #4: Tips for new developers regarding comments? 1. Taking time to look through the codebase. 2. Checking how and where comments are being used by other developers. 3. Refactoring the code to write more readable functions wherever things are unclear, using good naming conventions. 4. Trying to write self-documenting code, asking a lot of questions to whoever has written the code including the reasons why it is written a certain way. 5. Not being afraid to add comments of your own.

In this week's episode of the DevEd podcast, the panelists talk on comments in programming. To give a context of the chosen topic, Joe mentions that he sends out regular newsletters to Thinkser.io subscribers related to a variety of concepts, and has recently been sending out some on code smells, in one of which he talks about commenting. He gives an idea of what code smells are, and shares his opinion on using comments. His point of view is that a comment can be looked at as a failure or an inability to express the code functionality or even the technology involved, or is needed to make the code completely readable to other programmers. Comments can become out of date or get replaced. The other panelists join in the discussion on whether comments are good or bad, and they state that for beginners they can be very useful while not so much for experienced programmers. Too many comments can cause a mess, so they ideally should be used for large complex functions. They are mostly used to specify if refactoring is needed at a later stage, they should explain the "why" instead of "how", and in general the code should ideally be self-sufficient. They talk about when do they actually like to use comments. If a certain piece of code is doing something unusual or non-obvious or might break the consistency with the rest of the code, then it is imperative to explain why it is written that way. It can also be a good idea to document things for new or junior developers in the team in order to explain what is going on or what should not be done, and also to pair program with them in case things are not clear. Commit messages could be a replacement for comments as well. Comments are also useful when static values and constants such as URLs or UIDs are used in the code, and for explaining specific error mechanisms. They share great practical advice for programmers who are in the earlier stages of their software development career and have generally been taught to use comments by their professors or mentors. The tips they give include taking time to look through the codebase, checking how and where comments are being used by other developers, refactoring the code to write more readable functions wherever things are unclear, using good naming conventions, trying to write self-documenting code, asking a lot of questions to whoever has written the code including asking the reasons why it is written a certain way, and not being afraid to add comments of your own. They then discuss some replies to the newsletter sent by Joe about code smells related to the importance of comments in the messy reality of engineering, pros and cons of their usefulness, tradeoff between maintaining self-documented vs heavily documented code. They end the show with picks. The DevEd podcast is produced by Thinkster.io and published by DevChat.TV. Panel Joe Eames Jesse Sanders Luis Hernandez Preston Lamb Mike Dane Sponsors Thinkster.io The Freelancers' Show React Round Up CacheFly Picks Luis Hernandez: Sourcetree Mike Dane: Google Fi Preston Lamb: Office Ladies podcast Jesse Sanders: Tesla cars Joe Eames: Gaslands Question #1: What are code smells? A pattern that indicates that there may be a problem in the code with a possibility of improvement. Question #2: When should comments be used? Comments could be useful for beginners, not so much for experienced folk. Too many comments can cause a mess, so they ideally should be used only for large complex functions. They can be used to specify if refactoring is needed at a later stage, and for explaining the "why" instead of "how". Question #3: What are some good reasons to use comments? 1. If a certain piece of code is doing something unusual/non-obvious/might break the consistency with the rest of the code. 2. For new or junior developers on the team in order to explain what is going on or what should not be done. 3. When using static values and constants. Question #4: Tips for new developers regarding comments? 1. Taking time to look through the codebase. 2. Checking how and where comments are being used by other developers. 3. Refactoring the code to write more readable functions wherever things are unclear, using good naming conventions. 4. Trying to write self-documenting code, asking a lot of questions to whoever has written the code including the reasons why it is written a certain way. 5. Not being afraid to add comments of your own.

En este episodio hablamos de las herramientas que conocemos y usamos en nuestro día a día, tanto dentro como fuera de Python. Algunas de las que comentamos: DB clients: DBeaver, TeamSQL, SQL Workbench/J, IntelliJ DataGrip Visualizadores de documentación: Zeal, Dash. Extensiones de Chrome. VCS: Magit, Kraken, Sourcetree, Hub. Diff view de PyCharm. Docker: minikube, k3s, kind (kubernetes in docker) Shell search tools: fzf (extensión de autocompletado “difuso” para la shell, extensible para escribir propios completadores), ag (silver searcher), rip grep. Shell tools: zsh, fish, ohmyzsh Gestores de gists y notas: Lepton, Cacher, deft mode in emacs, nvalt. bear (editor de pago para notas en móvil), orgmode, babel-org, orgzly, orgmode. Gestores de tickets: JIRA, Trello. Opciones: Alternativeto.com

В этом выпуске ведущие рассказали о себе: — О том, как они пришли в программирование, какой тернистый путь прошли, чтобы прийти к тому, что у них есть сейчас; — О том, влияет или нет наличие диплома на работу — Что для нас продуктовая разработка и как на это оказывает влияние архитектура; — Как у кого строится рабочий день, в каком режиме кто работает, чтобы достичь дзена, работает или нет техника Помодоро; — Какие инструменты им помогают достигать поставленных целей: Xcode или AppCode? Android Studio или Android Studio :trollface:? Vim или Emacs? Любимый git клиент? Упомянутые в этом выпуске программы: - GitUp, http://gitup.co - Fork, https://git-fork.com - SourceTree, https://www.sourcetreeapp.com - Dash, https://kapeli.com/dash - MindNode, https://mindnode.com/mindnode/mac - Snitch, https://www.obdev.at/products/littlesnitch/index.html - MicroSnitch, https://www.obdev.at/products/microsnitch/index.html

Show Notes:* Git Documentation: https://git-scm.com/docs/git* SourceTree: https://www.sourcetreeapp.com* Git Tower: https://www.git-tower.com/mac/ * GitHub: https://github.com* Bitbucket: https://bitbucket.org* Malazan Book of the Fallen: https://www.amazon.com/Complete-Malazan-Book-Fallen-ebook/dp/B00HL0MA3WBlind Love Dub by Jeris (c) copyright 2017 Licensed under a Creative Commons Attribution (3.0) license. http://dig.ccmixter.org/files/VJ_Memes/55416 Ft: Kara Square (mindmapthat)

Přihodilo se nám léto, tak jsme tentokrát sedli ve dvou a popovídali o tom, jak využíváme nástroje pro správu zdrojového kódu, proč to vlastně děláme, jaké máme nejradši a podobně. Mimo jiné se také dozvíte, jak přispívat k vývojářské dokumentaci Microsoftu. Odkazy: - Git a Visual Studio: https://www.visualstudio.com/en-us/docs/git/gitquickstart - interaktivní Git tutoriál: https://try.github.io - Vojtův GitHub: github.com/madrvojt - Martinův GitHub: github.com/msimecek - výukové materiály na Xamarin: https://github.com/madrvojt/school-materials - SourceTree - https://www.sourcetreeapp.com/ - Hugo: http://gohugo.io/ Twittery atd.: - https://twitter.com/deeedx (Martin) - https://twitter.com/madrvojt (Vojta) Pokud nechcete, aby vám unikla nová epizoda, odebírejte RSS nebo nás sledujte na Twitteru: https://twitter.com/dotnetcezet Hudba pochází od Little Glass Men: https://freemusicarchive.org/music/Little_Glass_Men/

This week's roundtable episode features a (mostly) silent co-host: Ikaros the official Glitch HQ office doge! While not distracted by adorableness, Martha gives a primer on Git and version control best practices, Stephen leads a discussion on art direction, and Mark tries to understand PC gamers. Feedback Form GLITCHCON Celebrates A Weekend Of Gaming - Troy Strand , Tech {dot} MN Version Control 0:03:58 Martha Megarry Category Production Tools Git Martha's Git workshop presentation slides - Martha Megarry A Short History of Git - git SourceTree GItKraken “Merging Unity scenes, prefabs and assets with git” - David Douglas Git for Unity Developers - Alistair Doulin GitHub Bitbucket Heroku "Pushing to multiple git repos" - Alex Armstrong Code School: Learn Git - Paolo Perrotta , Code School Art Direction 0:33:38 Stephen McGregor Category Art In our episode " Bananas from here to eternity" the third topic in the roundtable is on Developer Art "Bananas, from here to eternity." "The Design Bible Behind New York City’s Subway Republished as a Limited-Editio… - Kristin Hohenadel , Slate SPY Fox Series Mini-Games Behind Borderlands' 11th-hour style change - Tor Thorsen Civ V Art Director Explains Art Deco Look - Adam Biessener , Game Informer Animation Bootcamp: Cuphead Process and Philosophy - Jake Clark , GDC Vault Console vs PC Development 0:54:44 Mark LaCroix Category Hardware Book Review: The Art of Game Design - Daniel Cook Valve making big changes to Steam's trading card economy - Derek Strickland , Tweak Town Sony Developer Program Xbox LIVE Creator's program ID@XBOX Becoming a Nintendo Switch indie dev will be tough early on - Kris Graft

David Power is a multi-purpose creative pro based in Brooklyn, NY. Since moving to New York, he's worked in music recording & production, written several business books, penned screenplays, and helped write and perform in comedy films. His latest project is a podcast documentary of how a feature film is made. Our conversation covers creative practices and routines, as well as the often-nebulous world of film & video, including how to collaborate on a script and using crowdfunding to launch projects at scale. Catch up with David on his website, DavidPower.com, or through his show, SureFirePodcast.com Get The Episode Download The Busy Creator Podcast, episode 96 (MP3, 44:01, 21.3 MB) Download The Busy Creator Podcast, episode 96 (OGG, 44:01, 24.9 MB) Subscribe to Get New Episodes     Subscribe to The Busy Creator Podcast on iTunes, on Google Play Music, on Android, on iHeart Sponsor Freedcamp, the finest free online project management software Bandwidth for The Busy Creator Podcast is provided by Freedcamp, Group Efforts Made Effortless. Freedcamp is best free online project management software available. By using the built-in functions and additional tools like time tracking, invoices, milestones, file storage, and more, teams can customise the software for the task at hand! The Busy Creator Podcast itself is managed and operated on Freedcamp. Get started for free on Freedcamp.com Show Notes & Links David's office is a multi-purpose room (writing, video editing, audio recording, podcast production) Acoustic paneling GIK Acoustics Reverb Anechoic Chamber David started making films based on his own whims and desires The Lonely Island Saturday Night Life D*ck in a Box David is currently podcasting the production of a feature film Michael Goldburg & Dave Chan, filmmakers Iron Mule Comedy Film Festival, NYC Seed & Spark, film-based crowdfunding platform Transcontinental Railroad Contractions (in dialogue) David's podcast episode on crowdfunding Crowdfunding article on The Busy Creator blog Kickstarter and pitch videos which now are their own project and format Cathryn Lavery on The Busy Creator Podcast, episode 65 American Sign Language (ASL) Does Google Docs have an offline version? Centered, Courier text for screenplays. Why? David has assembled a 3-monitor desk setup over the years Island of Misfit Toys Crysis Ivy Bridge, Intel's best chip from Spring 2012 David worked in a corporate environment for many years; no longer uses an alarm clock Prescott watches one event on broadcast TV each year: The Oscars Presidential debates in 2016 were streamed on Twitter DavidPower.com Sure-Fire Podcast  David Power on Facebook  David Power on LinkedIn Tools Trello Slack Google Docs FinalDraft BitBucket (on the web) SourceTree (on the desktop) Dropbox Paper Dell PC Tower from 2009 VEGAS Pro by Sony Magix Cakewalk by Sonar Hackintosh Mac Pro Techniques Soften the corners of a room to dampen reverb/echo Develop characters first, give them a voice and backstory, and then place them into a three-act structure. (Or not). Collect all notes and ideas; save them for later and vetting each one before writing Build a project management software workflow that actually reflects the way you work Don't store files in Slack; that's not the place for permanent items Use Plain Text formatting as a universal standard Build a Hackintosh if you can't afford a Mac Pro (which you probably can't) Habits Cross-promote, tag, and share your social links with your collaboration partners Exercise first thing in the morning Meditate, eat, drink coffee before starting work Use a floating lunch hour Wake up without an alarm Don't actively seek out news (minus industry happenings) Try Audible.com Free for 30-Days Visit BusyCreatorBook.com for your free trial Get Finish the Script!: A College Screenwriting Course in Book Form by Scott King as a free audiobook   

Check out iOS Remote Conf!!!   01:27 - Hardware 06:51 - Cloud Storage Dropbox iCloud 09:00 - Tools Xcode BBEdit TextMate Dash Emacs AppCode ReSharper Sublime Text Git Tower SourceTree 13:14 - Continuous Integration Jenkins CircleCI 18:11 - TestFlight 19:57 - Desk Setups Lifehacker Ikea Desk Herman Miller Spotify 26:06 - Coding Music Bach Cello Suites    Gustav Mahler - Symphony No. 1 - Bernstein · Vienna Philharmonic Orchestra   Nashville (Bill Frisell Album) The Masters of Classical Music - Vivaldi White Noise 30:28 - Miscellaneous Gear PlugBug Picks Open Radar (Andrew) Filing radars with Apple (Andrew) Twin Peaks (Jaim) Torrentz (Chuck) Come see the iPhreaks at Microsoft Build Conference! (Chuck)

Check out iOS Remote Conf!!!   01:27 - Hardware 06:51 - Cloud Storage Dropbox iCloud 09:00 - Tools Xcode BBEdit TextMate Dash Emacs AppCode ReSharper Sublime Text Git Tower SourceTree 13:14 - Continuous Integration Jenkins CircleCI 18:11 - TestFlight 19:57 - Desk Setups Lifehacker Ikea Desk Herman Miller Spotify 26:06 - Coding Music Bach Cello Suites    Gustav Mahler - Symphony No. 1 - Bernstein · Vienna Philharmonic Orchestra   Nashville (Bill Frisell Album) The Masters of Classical Music - Vivaldi White Noise 30:28 - Miscellaneous Gear PlugBug Picks Open Radar (Andrew) Filing radars with Apple (Andrew) Twin Peaks (Jaim) Torrentz (Chuck) Come see the iPhreaks at Microsoft Build Conference! (Chuck)

Assign It To Me Podcast #47 Image from Mashable Intro Naked Pictures online - Nude Celebrity Photos - Digg.com Articles Email will last forever - Front The Technology that Ruined Baseball - The Atlantic Topic Hipster Scarf Guy - Mashable Apple’s Keynote - Iphone 6, IOS 8, Apple Pay, Smartwatch State of the App State of the Stack Picks of the show: Steven: Sourcetree & Google Pagespeed Insights Vince: Slack

PodLuolan syvyyksissä pyyhitään pölyjä podcast-laitteista ja sukelletaan versionhallinnan maailmaan. Tutustutaan hieman Gitin, SVN:n ja Mercurialin käyttöä helpottaviin työkaluihin. Lyhyet esittelyt saavat Git Tower, SourceTree, Versions, CornerStone, TortoiseSVN sekä TortoiseGit. Versionhallinnan lisäksi tutustutaan eroavaisuuksien tarkasteluun erikoistuneisiin työkaluihin. Näitä ovat mm. DiffMerge ja Kaleidoscope. Ulkopuolista versionhallintapaikkaa tarjoavat esimerkiksi GitHub, Bitbucket ja Beanstalk. Sekä maksullisena että maksuttomana. Mikäli omaa kokemusta näistä tai muista vastaavista palveluista löytyy niin laittakaa palautetta. Palautekanavina ovat alla oleva foorumi, Twitteristä @FrontendFriday, Facebookista Frontend Friday sekä sähköpostitse ouluweb@gmail.com

In this episode we talk to Johannes Schindelin from the msysgit project, a tool used for building Git for Windows. 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 mp3Johannes is a mathematician with a degree in genetics. In his day job, he supports biologists with image processing and analysis. He is involved in a number of Open Source projects and he co-maintains Git for Windows with Sebastian Schuberth, Pat Thoyts and Erik Faye-Lund. He is from Germany, but currently lives in the Mid-West of the US.Note: We briefly discussed libgit2 being licensed as BSD. This is not the case anymore: It has switched to GPLv2 with a linking exception,Links:Johannes on Google+, GitHubJohannes' first OSS project: LibVNCServer/LibVNCClient(Fancy redesigned) MsysGit homepage Git for Windows wikiMailing list/forumThe “garden shears”Explanation what the “garden shears” are all aboutThe git-svn ref issue The newly redesigned msysgit homepage sourcesInteractive rebase with Eclipse EGitInteractive rebase with SourceTree (this was released right after we recorded)Installing Git for Windows from within Visual Studio (video)Listen to the episode on YouTube

This episode we're talking to Karoline Klever and Arve Systad from the Norwegian company Epinova, working with a .Net based CMS called EPiServer. They're well on their way migrating to Git and I wanted to hear how it's working out for them. 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:Arve on Twitter, GitHub, homepageKaroline on Twitter, GitHub, blogTools used at Epinova: SourceTree (Git GUI tool)Atlassian Stash (repository manager)Resources used for migrating to git: The ProGit chapter on Migrating to GitThomas' screencast on repairing git-svn repos using graftsResources for learning Git:Pro Git bookgit-scm.com videosTry GitGit for beginners: The definitive practical guide (from SO)One Git cheat sheetAnother Git cheat sheetOther things we talked aboutGitMinutes #05: Git in Visual Studio and TFSThomas’ Git setup on Windows Nuget, Chocolatey, posh-gitHave Git use credentials from encrypted netrc file Arve’s open source QA “checklist” toolWhat I totally forgot to mention was that there are a couple of alternative command line tools for Windows that can wrap Powershell, or any other shell inside:Console2 (sleeping project, but still works great) ConEmu Scott Hanselman's verdict of the two choices above Listen to the episode on YouTube

Bienvenue dans le soixante-huitième épisode de CacaoCast! Dans cet épisode, Philippe Casgrain et Philippe Guitard discutent des sujets suivants: Çingleton 2011 - Nos impressions SourceTree - Gratuit pour un temps limité SVProgressHUD - Affichez la progression de manière pro HGPageScrollView - Affichez des pages miniatures comme dans Safari Quicklook - Pour voir le contenu des vos fichiers d'approvisionnement InfColorPicker - Pour choisir des couleurs sous iOS programmers-killswitch - Quand vous en avez marre d'Xcode et Instruments Ecoutez cet épisode