Compare commits
No commits in common. "fb2758a17647d04f8fe4692bbdbaba411cc61021" and "e4dda25041b8bee86aab0f7c07ad0d06b68d8681" have entirely different histories.
fb2758a176
...
e4dda25041
|
@ -1,6 +1,5 @@
|
|||
+++
|
||||
title = 'about'
|
||||
draft = false
|
||||
+++
|
||||
|
||||
![](taco.png)
|
||||
|
|
|
@ -1,6 +0,0 @@
|
|||
+++
|
||||
title = 'posts'
|
||||
draft = false
|
||||
+++
|
||||
|
||||
posts i done gone and wrote
|
1
content/posts/index.md
Normal file
|
@ -0,0 +1 @@
|
|||
|
|
@ -19,8 +19,6 @@ tags:
|
|||
- "website"
|
||||
- "websites"
|
||||
coverImage: "image.png"
|
||||
aliases:
|
||||
- "/2023/10/06/moving-on-from-freenom"
|
||||
---
|
||||
|
||||
> why am i still hanging on?
|
After Width: | Height: | Size: 509 KiB |
After Width: | Height: | Size: 139 KiB |
After Width: | Height: | Size: 779 KiB |
After Width: | Height: | Size: 1,022 KiB |
After Width: | Height: | Size: 25 KiB |
After Width: | Height: | Size: 352 KiB |
After Width: | Height: | Size: 37 KiB |
|
@ -0,0 +1,156 @@
|
|||
---
|
||||
title: "[old] 9 agile techniques that will change your life"
|
||||
date: "2016-09-07"
|
||||
tags:
|
||||
- "agile"
|
||||
- "english"
|
||||
- "productivity"
|
||||
- "programming"
|
||||
- "tech"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from 2016.
|
||||
|
||||
![](images/846ce-1fnukauh56gz0ntn24ost2a.png)
|
||||
|
||||
#### Learn about TDD, OKRs, CI, CD and more!
|
||||
|
||||
You’ve probably heard of Agile development somewhere. It’s one of the most popular ways of making software these days. With Agile development, you can pump out functioning software within a few weeks and make both your developers and your clients happy.
|
||||
|
||||
Here are nine Agile techniques that have helped us here at [devAcademy](https://medium.com/u/e90784f3811e), and that can help you, too.
|
||||
|
||||
* * *
|
||||
|
||||
### 1\. Test Driven Development
|
||||
|
||||
TDD is one of the most popular development processes today, encouraging a sense of confidence in one’s code and helping you provide simpler answers to problems. With the [wide variety of testing frameworks available for every programming language out there](https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks), there’s no excuse not to implement TDD in your project.
|
||||
|
||||
TDD is a way to define requirements needed to be met through detailed and specific test cases. Afterwards, software is improved to only pass the new tests. Simply put:
|
||||
|
||||
- Find out what you want to add.
|
||||
|
||||
- Write tests for what you want.
|
||||
|
||||
- Write enough code to make your tests pass.
|
||||
|
||||
- ???
|
||||
|
||||
- Profit!
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/1ea23-1kuocwnkdwmkkk3tev36m4g.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
You see that right there? That’s TDD in action.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
Obviously, your tests should include some sort of system of verification that the desired result is achieved correctly. Your test code should also have the same upkeep and maintenance as your production code — it’s important! Your tests shouldn’t depend on states of the machine you’re testing on, and tests shouldn’t depend on each other. They should be fast to execute and easy to integrate on any machine.
|
||||
|
||||
On our Ruby projects, we use a combination of [RSpec](http://rspec.info/) and [Shoulda](https://github.com/thoughtbot/shoulda) to write awesome, transparent tests for our code. Find a testing framework that’s right for you and go wild with it.
|
||||
|
||||
### 2\. Continuous Integration
|
||||
|
||||
When we make things, we normally make a branch for each feature that we’re making, then merge it back into the master branch after we’re done modifying our own code. This makes sure that everyone always has the most updated version of our code.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/be0f4-1gmufdl3fkgkgwxljtekwaw.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Go with the [flow](https://guides.github.com/introduction/flow/)~
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
Keep your branch updated and make sure your code is available to everyone when you’re done with it. We use platforms like Travis CI to make sure that our code is fully functioning with tests and code quality checks when we merge something to master so that our modifications to the master branch don’t affect everyone else negatively.
|
||||
|
||||
### 3\. Continuous Deployment
|
||||
|
||||
When I make something new, I always get antsy. I want my new code to be out there as fast as possible, and here at dev we feel like it’s a crucial part of development — new issues get found faster and more efficiently, and features are pushed out rapidly.
|
||||
|
||||
There are a few drawbacks to Continuous Deployment, just like there are in Continuous Integration, but the benefits vastly outweigh the consequences. Your users can experience your latest features within moments of you pushing your code to your repos and can give you feedback in real time. There are no wait times to let your users get that fresh code smell; they get the latest code, all the time.
|
||||
|
||||
\[embed\]https://stories.devacademy.la/this-is-what-youre-missing-out-on-with-continuous-deployment-afa6b49c4c8c\[/embed\]
|
||||
|
||||
### 4\. Daily stand-ups
|
||||
|
||||
The best teams make sure that they’re all on the same page. You can’t work on a project together unless you know what everyone is doing. Daily stand-ups help teams work in synergy, letting others know what’s on your plate and your daily progress.
|
||||
|
||||
![](images/6a248-1edncfgm8vobt9moh2e94kw.png)
|
||||
|
||||
A normal stand-up consists of three questions presented to all team members:
|
||||
|
||||
- **What did you do yesterday?**
|
||||
|
||||
This question lets your team members know what progress you made on the things you were going to do yesterday, and if you completed them or not. It also makes sure that your other teammates are informed on activities that happened yesterday so they don’t repeat objectives in their work today.
|
||||
|
||||
- **What did you do today?**
|
||||
|
||||
This questions lets your team members know what you’re going to do today. It also informs your teammates on things that they should try to work on with you and collaborate with so you can achieve your objectives faster.
|
||||
|
||||
- **Is anything hindering your progress?**
|
||||
|
||||
This is probably the most important question in a stand-up. Being open and honest about our faults helps us grow as people in general. If something was blocking your progress, it doesn’t make you a worse person, it just means you need to improve in that area. That’s the whole point of being agile — identifying obstacles quickly and resolving them quicker.
|
||||
|
||||
### 5\. Pair programming
|
||||
|
||||
The best ideas and the best projects have been made by working together. In our personal experience, we’ve found that tacking two people onto one objective helps a lot — you have someone else to bounce ideas off of and it distributes some of the load that comes with each objective.
|
||||
|
||||
![](images/9bc97-1u0mw6jbas3wbth0fwnazvg.png)
|
||||
|
||||
Another person can also help remind you of what goals you need to reach together. With someone else on your team, you can reach objectives faster since there’s someone to corroborate your work.
|
||||
|
||||
### 6\. Retrospectives
|
||||
|
||||
Here at [devAcademy](https://medium.com/u/e90784f3811e), we have a weekly meeting to review what we did last week, how we did it, how/if we failed at doing something, and how we contributed to our Objectives and Key Results this week.
|
||||
|
||||
> Coding isn’t just a way to make computers do things — it’s a personal journey of finding a digital solution to a problem.
|
||||
|
||||
Coding isn’t just a way to make computers do things — it’s a personal journey of finding a digital solution to a problem. Retrospectives let us help others provide input on everyone’s progress so we don’t feel alone on our programming expedition.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/4bce5-0zzdmerebdnkfeoj_.jpg)
|
||||
|
||||
<figcaption>
|
||||
|
||||
[What a retrospective looks like at devHouse](https://www.facebook.com/devacademyla/photos/a.356158231151265.1073741827.316005858499836/838163579617392/)
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
In Agile development, one of the most essential parts is communication. This helps us achieve just that. We have a meeting every Friday morning to socialize and check on our progress as a team. You should, too.
|
||||
|
||||
### 7\. Planning
|
||||
|
||||
This is really a no-brainer. You should always make sure that your activities are planned out with some tool that fits in with Agile methods. We use Basecamp, but you can use tools like Trello, Asana, or even plain old Google Calendar for planning out things with your team.
|
||||
|
||||
Making sure you have a set timeline makes sure that you can verify that you’re getting work done efficiently. If you can meet your goals before the allotted time frame, you’re probably doing way better than you planned, which is great! Having something to refer to in terms of your progress helps you easily and transparently analyze what you need to improve on, and how to pace yourself.
|
||||
|
||||
### 8\. Code reviews
|
||||
|
||||
Your code isn’t always going to be the best. Sometimes you think your code is awesome, but you haven’t seen the glaring security error or possible cases that could creep up on you in production. That’s why we review each other’s code here at [devAcademy](https://medium.com/u/e90784f3811e). By implementing pair programming, this should be really easy. Your partner and/or supervisors should be able to check your code easily and transparently.
|
||||
|
||||
> In Agile development, transparency and communication is essential.
|
||||
|
||||
![](images/8cd41-1vto_rjkx4oopljeuuvtq9a.png)
|
||||
|
||||
We use GitHub for our code, so we normally comment on our pull requests so we can scrutinize the code we’re working on! That way our entire team is on the same page and we can see why we did/didn’t merge something to the master branch. In Agile development, transparency and communication is essential, and this helps us achieve just that.
|
||||
|
||||
### 9\. Objectives and Key Results
|
||||
|
||||
Have you ever had a big project that you really want to finish, but don’t know where to start? OKRs can help you out with that. This technique of planning out progress and key points in your project came to be in 1999 at Google, and since then they’ve dominated the market by using this technique. Maybe they’re onto something, eh?
|
||||
|
||||
A good objective encompasses a big goal, answering what your final ambition is. It can be something like “Adopt Agile development techniques”. The point is to have something to work up to.
|
||||
|
||||
Good key results show you the details of the journey you’re about to take. They’re small steps towards your goal, and they don’t always have to be linear! Things like “Educate team members about Agile techniques”, “Improve productivity using Pair Programming” and “Use OKRs to plan out our next project” are all awesome Key Results because they talk about steps to reach your objective.
|
||||
|
||||
Once you have some OKRs planned out, you’ll start to notice that you’re going to be more organized and get more stuff done as a team. You’ll also feel awesome when you cross one of those Objectives off! It’s a great experience.
|
After Width: | Height: | Size: 436 KiB |
After Width: | Height: | Size: 748 KiB |
After Width: | Height: | Size: 869 KiB |
After Width: | Height: | Size: 784 KiB |
After Width: | Height: | Size: 87 KiB |
After Width: | Height: | Size: 728 KiB |
84
content/posts/old/a-new-chapter/index.md
Normal file
|
@ -0,0 +1,84 @@
|
|||
---
|
||||
title: "[old] a new chapter"
|
||||
date: "2017-07-30"
|
||||
tags:
|
||||
- "english"
|
||||
- "life"
|
||||
- "productivity"
|
||||
- "startup"
|
||||
- "tech"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing. it's from 2017.
|
||||
|
||||
#### On new endings and old beginnings
|
||||
|
||||
I joined dev in December of 2016. It was my first time dealing with a working environment, and it's been a pretty awesome ride.
|
||||
|
||||
![](images/5125e-1vdlg71admo2fwqyuu4lofw.png)
|
||||
|
||||
[Lennon](https://medium.com/u/57f86eb26cec) was doing a workshop on Ruby on Rails in Ecuador and noticed I wasn’t half bad with code. Or maybe he noticed I was terrible and needed to fix me up. I like to think it's the former, though. He offered me a position to do part-time work at dev remotely to hone my programming skills. It was a big commitment and lots of hours in Starbound were traded for it, but I agreed.
|
||||
|
||||
Working remotely was a unique experience. Being far away from your coworkers feels somewhat isolating, but you get the freedom of being able to do work at home, in your pajamas. I made my own schedule and worked my solid 4 hours a day after class, mainly working on the [devAcademy website](https://devacademy.la).(A lot of people say that staying in your pajamas makes you less productive, but I disagree.)
|
||||
|
||||
I worked part-time for a year before getting an offer to work full time for dev here in Peru. Moving to Peru was pretty daunting and the second largest move I’ve ever done, but it was worth it.
|
||||
|
||||
![](images/76d25-1y1zw_kyesuelvht5afvdwq.png)
|
||||
|
||||
The move itself was pretty smooth, but took a long time. I had to take a bus to Lima, which took about 36 hours total. I finally watched Fight Club on the way there, though, so it wasn't all in vain. The trip was nice, and I received a warm welcome from the team once I arrived.
|
||||
|
||||
![](images/9235d-1yhaes2jr1mzql6q67gieqq.png)
|
||||
|
||||
All of my coworkers were super helpful in helping us get settled in Ica. Without them, I don’t think we would have survived around here. I learned a lot about life in Peru! Living here in Ica was quite the experience. I’d definitely come visit here again. Ica is cheap to live in and a literal oasis in the middle of the desert. The people are nice, the food is great and I think I have a crippling addiction to [Chocotejas](http://perudelights.com/chocotejas-confections-from-the-desert/). They even celebrated my mom's birthday, which I think was super cute.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/b13e5-1tyapeerxd-xz3smovqmqeq.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
They call cake “keke” here. Top kek(e).
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
On the off-chance I wasn’t coding, I did tourism around Ica. I visited Huacachina, walked around the malls around here, and learned about the history of this little desert oasis. Ica is a bustling and growing place, and I’m glad to have been a part of it for as long as I was. It’s a great city to be in.
|
||||
|
||||
I also took some driving lessons! I only crashed, like, once.
|
||||
|
||||
![](images/828ad-1qg8dvudoturyt7t8pl13zw.png)
|
||||
|
||||
Apart from life experience, I got a lot of work experience that I couldn’t have gotten anywhere else. I learned a lot at dev:
|
||||
|
||||
- I refined my skills in Ruby on Rails and JavaScript. Rails is my go-to for web development and JavaScript/Node is my go-to for other projects now.
|
||||
|
||||
- I learned a lot about emerging software like React Native. Sharing codebases across mobile OSes? Crazy stuff. I feel like this is the start of a new era for applications everywhere.
|
||||
|
||||
- I learned how to write code for Alexa Skills. I’m really excited to see how the Internet of Things evolves with new tech that allows us to interact with software in ways previously unimaginable.
|
||||
|
||||
- I figured out how to manage a social media account with over 7k followers and aggregate content that would promote users like you and me in the tech community. Probably the second scariest thing I’ve done.
|
||||
|
||||
- I learned how to work with clients on a 1 to 1 basis. Probably the scariest thing I’ve done, but I know that I’ll have to do it again soon.
|
||||
|
||||
- I learned how to code in, uh… Java, which wasn't my, uh… favorite… experience.
|
||||
|
||||
- I even learned about networking and setting up routers!
|
||||
|
||||
devAcademy has been a key stepping stone in the upwards climb to the best me I can be. I’m glad to have been a part of the team here for as long as I was. It was essential to me being who I am now. I’ve learned a lot about how to value my own work and the work of others while cooperating in a team.
|
||||
|
||||
I’m even more excited about code. It’s something I’m very passionate about, and working here at dev has cemented that for me. I want to build things that people can use and enjoy, and working here has been a learning experience through and through.
|
||||
|
||||
From what I’ve learned here at dev, I know that I don’t know everything, and I probably never will. But that shouldn’t stop me from pressing on forward and doing my best in whatever I know how to do now.
|
||||
|
||||
Someday I hope to work with Lennon once again, but for now…
|
||||
|
||||
New places to go.
|
||||
|
||||
New people to see.
|
||||
|
||||
New code to write.
|
||||
|
||||
New adventures to be had.
|
||||
|
||||
![](images/9a03a-1epqtbzfgktmo-yz4c1i79a.png)
|
After Width: | Height: | Size: 54 KiB |
After Width: | Height: | Size: 102 KiB |
After Width: | Height: | Size: 54 KiB |
After Width: | Height: | Size: 26 KiB |
After Width: | Height: | Size: 28 KiB |
After Width: | Height: | Size: 29 KiB |
After Width: | Height: | Size: 16 KiB |
After Width: | Height: | Size: 102 KiB |
108
content/posts/old/everhour-vs-hubstaff/index.md
Normal file
|
@ -0,0 +1,108 @@
|
|||
---
|
||||
title: "[old] everhour vs. hubstaff"
|
||||
date: "2017-01-11"
|
||||
tags:
|
||||
- "english"
|
||||
- "everhour"
|
||||
- "startup"
|
||||
- "tech"
|
||||
- "time-management"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from 2017.
|
||||
|
||||
![](images/cd7de-177ylvnpfmzpdvg6-8zzbwq.png)
|
||||
|
||||
#### What the difference is, and why you might want to switch
|
||||
|
||||
Here at [devAcademy](https://medium.com/u/e90784f3811e) we constantly strive to make ourselves better and find the tools to make our workflow more efficient and streamlined. This helps our developers be less stressed about the way they manage their time, leaving them to focus fully on the work they need to do.
|
||||
|
||||
Recently, we tried out [Everhour](https://everhour.com/?utm_source=devacademy&utm_campaign=k-devacademy-medium&utm_medium=blog) and implemented it into our workflow. After trying it out for a week, we’ve decided we want to stick with it. Here’s why.
|
||||
|
||||
#### Reporting vs. Tracking
|
||||
|
||||
If you look at our previous articles, you’ll notice that we were using Hubstaff before we switched. Hubstaff’s workflow focuses on tracking what hours you’ve worked. Everhour focuses on tracking the tasks you’ve completed instead, letting your working hours be a bit more flexible.
|
||||
|
||||
That’s not to say that Hubstaff isn’t good — Hubstaff is actually pretty good! Their billing system helped us pay our employees by the hour according to what they really clocked in, but we soon realized that it didn’t fit our agile workflow. Hubstaff works best in companies using a more traditional workflow, one where the time spent on a project is more valued than the final product itself.
|
||||
|
||||
![](https://cdn-images-1.medium.com/max/800/0*wWduLU_7L61QPSfL.)
|
||||
|
||||
We focus more on providing our clients with a quality final product, so time tracking isn’t as important. We contract our part-time employees per project, not per number of hours. With our agile way of working, we can’t set rigid time frames on the projects we work on — it breaks the flow of what needs to be done.
|
||||
|
||||
By using Everhour, we’re able to more easily quantify how long we’ll take on a project without feeling pressured to complete our work. We can take our time on each project and work without feeling the weight of an impending deadline on our shoulders.
|
||||
|
||||
#### Keeping ourselves secure and trusting ourselves
|
||||
|
||||
Our old tool had a feature that took screenshots periodically. This feature allows higher-ups in the company to review and check what we were really doing in the time we tracked. This doesn’t really work in our company, though. We all felt like we were being watched over our shoulder, and like we weren’t trusted enough to get stuff done.
|
||||
|
||||
Here at devAcademy, we believe in everyone having an equal footing, where titles shouldn’t matter and where ideas can flow. This tool unintentionally created a hierarchy of people who administrated the tool, making others feel inferior and uncomfortable. This is not to say that the tool is bad — it just doesn’t work for us.
|
||||
|
||||
Along with that anxious feeling that being watched, we noticed that the only transparent way to track what we we’re doing is by taking screenshots without blurring them. This poses a new problem.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/bd437-0ven-lxa4shczster.jpg)
|
||||
|
||||
<figcaption>
|
||||
|
||||
[\[Watching the Watchers — Carsten\]](https://stock.tookapic.com/photos/56574)
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
Any security buff knows that taking screenshots periodically and sending them to the cloud can invite people to try and peek on personal information that you access while you’re working. The images taken can include passwords and key parts of the projects we were working on that we didn’t want to make public. This is a problem that worried many of our developers.
|
||||
|
||||
By using Everhour, we’re able to feel less restricted and work freely without having to avoid things that could otherwise expose parts of our personal life, like bank statements or access keys. Many of us have reported feeling like we can be more relaxed here with how we tackle problems, letting our work flow freely instead of being restricted to a rigid time frame.
|
||||
|
||||
#### A seamless reporting experience
|
||||
|
||||
Have I mentioned Everhour’s Chrome Extention? It’s pretty awesome. It integrates directly into Basecamp, allowing us to get to work on tasks in Basecamp 3 right away instead of having to switch to another app. This seamless integration into the apps we already use lets us implement it without an extensive onboarding — we can just use Everhour as if it were a natural thing to do.
|
||||
|
||||
With Hubstaff, we had to switch to another application and wait for all of our Basecamp 3 tasks to sync with their API to begin working. This happened _often_. With Everhour, we’re able to get start working right when we assign/we’re assigned tasks.
|
||||
|
||||
![](images/cef75-1tnaxnkod-ua-jubkybbjjq.png)
|
||||
|
||||
Along with letting us track time, Everhour lets us estimate the amount of time we might spend on a project, letting us better plan out our list of things to tackle this coming week. The best part about all of this is, it’s all right there in Basecamp! It’s so seamless that you don’t even have think about adding an estimate, it seems like part of the natural process of adding a new To-Do.
|
||||
|
||||
![](images/981e4-13g0n1g8n-q-2iybduwbigw.png)
|
||||
|
||||
Another thing we adore about Everhour is their rigorous reporting system. We highlighted how much we like reporting in our Basecamp article, and this system helps us integrate Everhour effortlessly with our workflow on Basecamp 3.
|
||||
|
||||
The last reporting system we used left us with much to be desired, so this is a breath of fresh air. You can create custom reports, which has a easy to use interface that allows you to change any aspect of how everything is presented to the other users.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/73d11-1tk52ev52bomsllbs7-2lxw.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Ricing time.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
This helps us with our daily report reviewing what we did yesterday and what we’re going to do today. In fact, we just include a screenshot of a predetermined custom report and describe what wasn’t “closed” yesterday that was left to be done today.
|
||||
|
||||
![](images/812c9-1yskjzal45dfzvfexvxgwbw.png)
|
||||
|
||||
This makes it easier for us to start our day and get informed on what everyone’s doing, refreshing ourselves on what we did yesterday and what needs to get done.
|
||||
|
||||
There’s a lot more to Everhour, and it has a lot of potential. We’re integrating it into our workflow because it works really well for us. It’s streamlined how we communicate with each other on what projects we’re doing. We think it’ll work great for you too.
|
||||
|
||||
If you’re interested in trying out [Everhour](https://everhour.com/?utm_source=devacademy&utm_campaign=k-devacademy-medium&utm_medium=blog), we have a special code just for our readers:
|
||||
|
||||
```
|
||||
devacademy
|
||||
```
|
||||
|
||||
This code will allow you to get a 10% lifetime discount on your [Everhour](https://everhour.com/?utm_source=devacademy&utm_campaign=k-devacademy-medium&utm_medium=blog) subscription. Use it when you’re checking out to take advantage of being one of our awesome readers. 😉
|
||||
|
||||
* * *
|
||||
|
||||
### If you really liked this post, be sure to click that little heart so that others can find it!
|
||||
|
||||
#### And if you liked this, you should check these articles out:
|
||||
|
||||
\[embed\]https://stories.devacademy.la/hello-basecamp-farewell-slack-35ed2e2de6b9\[/embed\]\[embed\]https://stories.devacademy.la/hello-basecamp-farewell-slack-35ed2e2de6b9\[/embed\]\[embed\]https://stories.devacademy.la/hello-basecamp-farewell-slack-35ed2e2de6b9\[/embed\]
|
20
content/posts/old/first/index.md
Normal file
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: "FIRST"
|
||||
date: "2023-10-05"
|
||||
categories:
|
||||
- "miscellaneous"
|
||||
---
|
||||
|
||||
<figure>
|
||||
|
||||
https://www.youtube.com/watch?v=BQClqtVdqsw
|
||||
|
||||
<figcaption>
|
||||
|
||||
you dont understand i made a really cool website please give me back my 3ds
|
||||
|
||||
</figcaption>
|
||||
|
||||
|
||||
|
||||
</figure>
|
After Width: | Height: | Size: 202 KiB |
After Width: | Height: | Size: 136 KiB |
After Width: | Height: | Size: 56 KiB |
After Width: | Height: | Size: 58 KiB |
After Width: | Height: | Size: 496 KiB |
After Width: | Height: | Size: 124 KiB |
After Width: | Height: | Size: 99 KiB |
142
content/posts/old/hello-basecamp-farewell-slack/index.md
Normal file
|
@ -0,0 +1,142 @@
|
|||
---
|
||||
title: "[old] hello, basecamp — farewell, slack"
|
||||
date: "2016-10-28"
|
||||
tags:
|
||||
- "communication"
|
||||
- "english"
|
||||
- "productivity"
|
||||
- "startup"
|
||||
- "tech"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from 2016.
|
||||
>
|
||||
> (i no longer recommend basecamp.)
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/93ff6-19wudiq3-onrs5yerswabrq.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
c:
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
#### Why we stopped Slacking and set up a Basecamp
|
||||
|
||||
We recently switched to Basecamp at [devAcademy](https://medium.com/u/e90784f3811e). We’ve used a few tools to organize and communicate within ourselves, but were never satisfied. We settled on Basecamp after reviewing a few options. Why are we taking the plunge? Let’s find out.
|
||||
|
||||
* * *
|
||||
|
||||
I have never met anyone who has told me that managing a company is easy. It’s actually quite hard, and many people will tell you the same.
|
||||
|
||||
Why?
|
||||
|
||||
Because you hired human beings.
|
||||
|
||||
![](images/ac1d6-14rnjkfsxp6uctmagcccllg.png)
|
||||
|
||||
It won’t matter if your team members come from the same school, like the same things, or work on the same things. They’ll always find a way to clash with each other. I’m not going to lie — I don’t always get along with everyone at dev, and that’s natural! You can’t expect others to get along with everything you do. It’s because you’re not a robot. It’s [only human](https://youtu.be/MXvVX3mI978?t=12). Luckily, that’s where Basecamp comes in.
|
||||
|
||||
Basecamp isn’t like Slack or Trello. It’s a project management system that works differently from anything else we’ve ever seen. Instead of using lists of cards like Trello, it uses a more forum-like discussion system. Blended with to-do checklists, this lets you manage your projects easier. Instead of having lots of channels like Slack, you simply chat in a per-project Campfire that’s already integrated into each project.
|
||||
|
||||
#### Let’s muse about management
|
||||
|
||||
Before moving to Basecamp, we tried a lot of platforms to work on projects together. Trello was one of the strongest competitors, and we used it for a long time. It’s the platform I was introduced to when I first joined devAcademy.
|
||||
|
||||
Trello is a project management application that’s entirely on the web. It’s really neat! The entire platform feels fluid and easy to use. They use the kanban paradigm for managing projects, which is separated into boards, which have lists (columns) of cards that let you organize tasks, each with their own to-do lists, descriptions, and comments.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/c92b5-1cejlmlda0syljfk05mikqg.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Kanban is a weird word, but it makes for a decent platform.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
Trello isn’t bad by any means, but it doesn’t fit our workflow. There’s no reporting system. This means that you have to manually search for the things that are due on someone’s plate. That’s time that we don’t have to dedicate to see what we need to do or what others need to do. Projects got dragged behind and people didn’t know what they needed to do. It lowered our productivity instead of elevating it.
|
||||
|
||||
Cards are great for collecting ideas, but they’re not good at giving you a list of things to do. The cards floated around and would always move from one list to another and we would never feel like we could check something off and finish it. It was archived and never seen again.
|
||||
|
||||
Basecamp 3 has a whole new way of looking at project organization. Tasks are now individual items in a to-do list, which you can check off when you’re done. (It’s satisfying.)
|
||||
|
||||
![](images/7e021-1zxm8vh5p5srz9afb3s751q.png)
|
||||
|
||||
Each item in a list can have anything you can imagine. You can add a due date, comment on it, attach files, assign it to someone… the list goes on. It’s super handy and fluid.
|
||||
|
||||
Another thing I’d like to gush about is Basecamp’s report system.
|
||||
|
||||
![](images/a7fbf-1v0myibwrnk1o2qitqd_qqg.png)
|
||||
|
||||
You can ask for a variety of reports in Basecamp 3, and each one provides insight on what everyone is doing or what everyone needs to do.
|
||||
|
||||
- “What’s overdue?” gives you a list of tasks that are overdue across your teams and projects. Super awesome for checking up on things that should’ve been done yesterday so you can remind yourself (and others) on what needs to be done!
|
||||
|
||||
- “What’s coming up or due soon?” gives you a nice list of chronologically organized tasks across all teams and projects that have a due date. It’s a way of knowing what to expect in the future without having to dig too much into your projects.
|
||||
|
||||
- “What’s new to-do and what’s to-done?” is a clever way of letting you know what things have been added to project checklists and what’s been completed.
|
||||
|
||||
- “What’s on someone’s plate?” gives you a nice list of things that someone needs to do. You can check if [Kattya](https://medium.com/u/7cd86522af8d) is going to host another devHangout this week, or if [Lennon](https://medium.com/u/57f86eb26cec) is going to [buy more Post-It notes today](https://www.facebook.com/photo.php?fbid=10209678661577801&set=a.4350837243595.2168310.1067527170&type=3).
|
||||
|
||||
- “What has someone been up to?” shows you what someone’s been doing! This is a great way to review someone’s progress on projects, or what they’ve been posting on Team Message Boards.
|
||||
|
||||
- “Who clapped for me?” 👏 check 👏 those 👏 mf 👏 claps 👏 so 👏 you 👏 feel 👏 good 👏
|
||||
|
||||
I’d like to emphasize that reports have helped us immensely at dev. We’re able to see everything clearly and micro-manage ourselves instead of relying on others to nudge us on things that we need to do.
|
||||
|
||||
#### Let’s chat about chatting
|
||||
|
||||
Along with switching out our project management for Basecamp’s, we migrated our chat from Slack to Basecamp. Slack isn’t a bad chat platform, by any means. In fact, I was singing [Slack](https://medium.com/u/26d90a99f605)’s praises a few months ago:
|
||||
|
||||
\[embed\]https://stories.devacademy.la/why-slack-is-the-best-chat-platform-for-your-team-a13cd07881\[/embed\]
|
||||
|
||||
Slack is a great hub for people to communicate with each other. They’re the best chat platform I’ve seen yet. They have awesome archiving, great unfurls, custom emojis and awesome mobile apps. They’re dominating the chat platform field.
|
||||
|
||||
![](images/fdf34-1yldut_yvqidlddtc0p4mja.png)
|
||||
|
||||
That doesn’t mean that it’s perfect, of course. Slack is not made for organizing ideas. It’s made for watercooler talk. Channels can be made for separate topics, but it’s a hell of a hassle to sift through the information presented. You have one of two options:
|
||||
|
||||
1. Make a billion channels and have nobody use any of them
|
||||
|
||||
3. Only have one channel and experience what the depths of hell feel like
|
||||
|
||||
Along with that, Slack pressures you into replying to comments and threads _right now_ instead of letting you take your time with messages. This can become an excessive, compulsive checking of your notifications, leading to less productive teams. These can cause unwanted anxiety, as well, even if it doesn’t mean to.
|
||||
|
||||
> “Have I checked my notifications recently? Is there a message I missed?”
|
||||
|
||||
Basecamp lets you organize all of your information and use message boards to post threads instead of cumbersome chat rooms. Important information can be sorted into teams, and it’s encouraged to use the message boards instead of chats, but the functionality is still there! Campfires are Basecamp’s chat hubs, where you can chat with everyone on that team about everything related to the topic at hand whenever you have a moment.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/7ab4b-1vtjbjr7fgbqc1gvljgsykq.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
The Surface Studio _does look pretty hella, not gonna lie_
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
#### Let’s speak of synchronousness
|
||||
|
||||
One of Basecamp’s biggest selling points is that projects can function better if work is asynchronous. A lot of chat platforms and time-saving tools overwhelm users with notifications at times. I really like what one of the founders of Basecamp has to say about interrupting people while they’re being productive:
|
||||
|
||||
> …very few things need to be resolved quickly. “Now” is a huge ask of someone else. You may care, but what someone else is already doing may be even more important. That’s why any forms of interruption should be used very carefully.
|
||||
|
||||
_\-_ [_Jason Fried_](https://medium.com/u/c030228809f2) _(_[_source_](https://medium.com/@jasonfried/my-fundamental-point-is-that-very-few-things-need-to-be-resolved-quickly-8f070ef5c6a#.oeunj9tk6)_)_
|
||||
|
||||
(Jason also wrote an awesome article on why he built Basecamp differently, which you can read [here](https://m.signalvnoise.com/is-group-chat-making-you-sweat-744659addf7d#.rtxx8qcv8).)
|
||||
|
||||
At [devAcademy](https://medium.com/u/e90784f3811e), we believe in creating an environment where our developers can code happily. If our team is happy, that means that our clients will be happier, because we’ll be making better products!
|
||||
|
||||
We switched to Basecamp because we want an easier way of knowing what’s on everyone’s plate. We wanted to reduce some of the stress that natural comes with work. It’s made us more productive and able to focus better on our tasks.
|
||||
|
||||
We think you should, too. ❤
|
After Width: | Height: | Size: 8 KiB |
After Width: | Height: | Size: 373 KiB |
After Width: | Height: | Size: 91 KiB |
After Width: | Height: | Size: 464 KiB |
After Width: | Height: | Size: 549 KiB |
After Width: | Height: | Size: 329 KiB |
|
@ -0,0 +1,180 @@
|
|||
---
|
||||
title: "[old] how to use github like a proper human being"
|
||||
date: "2016-08-01"
|
||||
tags:
|
||||
- "coding"
|
||||
- "english"
|
||||
- "github"
|
||||
- "programming"
|
||||
- "tech"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from 2016.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/474c4-1kqhihffhcr2ewixsov13wg.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
[Founding Father Octocat v2 by James Kang](https://octodex.github.com/foundingfather_v2)
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
#### Learn some etiquette, man.
|
||||
|
||||
Our repo organization can suck sometimes. Here’s how to make it less sucky.
|
||||
|
||||
#### Commits
|
||||
|
||||
I’ve seen (and made) so many bad commit messages at [devAcademy](https://medium.com/u/e90784f3811e). We should really start to charge 10 cents for each bad commit someone makes one. We’d make [millions](https://www.youtube.com/watch?v=EJR1H5tf5wE).
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/f6b85-1_cjzykncqyesud_hlogc0a.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
100 million dollars, to be exact
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
We can settle this once and for all, though, by remembering a few guidelines when we commit anything on GitHub. And I mean **ANYTHING.** Personal projects, projects at work, even projects that you think will never see the light of day.
|
||||
|
||||
Once you get the habit of making awesome commit messages you’ll start doing them reflexively. You won’t have to put effort into making them. Your coworkers might like you more, too. _Might_.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/9c11c-1t8rlsnjffiarxbaah6ioew.gif)
|
||||
|
||||
<figcaption>
|
||||
|
||||
reflexive\_commits.gif
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
When making a commit, I normally follow [this short list of guidelines by Chris Beams](http://chris.beams.io/posts/git-commit/), along with the [git style guide](https://github.com/agis-/git-style-guide). Here’s what I’ve learned:
|
||||
|
||||
- **Keep your commits atomic.** What’s this mean? [Fresh Consulting says](http://www.freshconsulting.com/atomic-commits/) that you should apply changes as you make them. Your commit should revolve around ONE change or fix. If you have to add an “and” in your commit message, you’ve already committed too much.
|
||||
|
||||
- **Keep your commit message under 50 characters.** Why? Shorter things are easier to read, like this sentence. Short and to the point.
|
||||
|
||||
- **Capitalize the first word your commit message.** This is seen as generally good conduct by most gitsperts. Sentence case is also more professional looking and easier to read. (See a pattern here?)
|
||||
|
||||
- **Don’t end your commit message with a period.** Leave people in suspense. Leave them wanting more. Also, you want to make sure your 50 characters are well spent.
|
||||
|
||||
- **Use an imperative commit message.** Make your commits sound like you gave a command to someone. Programming is normally defined as “ordering your computer to do things”, so might as well keep that reputation up, right?
|
||||
|
||||
- **Use the same language in your commit messages.** Most people seem to use English as their preferred language, but it doesn’t mean you have to. What you do have to do is be consistent. Don’t mix phrases in one language with another language.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/2836b-16utifimt4z-d80ulvdsgaa.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
DON’T DO THIS. PLEASE. NOBODY LIKES SPANGLISH.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
“_Refactor mediumExample() function”, “Remove unnecessary line in bot.js”,_ and _“Add SASS gem to gemfile_” are all good examples of easy to understand atomic commits that describe the action you’re doing in 50 characters or less. They might seem like unnecessary fluff to you, but when you or someone else needs to find a specific change you made in the past, they’ll thank you endlessly.
|
||||
|
||||
#### READMEs
|
||||
|
||||
I’ve seen so many projects with lackluster READMEs it kind of makes me sick. This is supposed to sell your project. When someone reads it, they have to be interested in your project in seconds. Only after that, they’ll consider reading further into it.
|
||||
|
||||
Here’s what I deem are necessary elements in a README:
|
||||
|
||||
- **A header image (_somewhat optional_).** Give people something to look at. They need to know what your project is at a glance. Maybe show them a screenshot with a logo placed on top, those are cool.
|
||||
|
||||
- **A title**. People need to know what your project is called. Make it obvious and make it stand out so people will remember it.
|
||||
|
||||
- **Some badges (_optional_)**. [Badges are cool, right?](http://forthebadge.com/) These should be important things like a Travis build status, Code Coverage or a David DM check or something like that.
|
||||
|
||||
- **A short description.** Twenty words or less. This small sentence should summarize everything that your project’s about. It’s your tagline, basically. Sell your project.
|
||||
|
||||
- **A small list of features.** Four to five things that say “Hey, this is what’s cool about this project!”. Get people interested in your project with some radical things that your product does.
|
||||
|
||||
- **A _short_ summary of installation and/or usage.** Your app should not take 10 paragraphs to describe how to install and/or use it, and you shouldn’t have to write an entire manual to quickly show some people how it works. Write up the quick, TL;DR version of installing and/or using your project. Nothing fancy, just enough to get people up and running.
|
||||
|
||||
- **External links to more documentation.** You wrote documentation for your project, right? _Right?_ **_RIGHT?!_** If so, _please_ don’t include the entirety of it here. GitHub has Wikis for your project, which makes for a much better method of presenting content, as opposed to one huge Markdown file. Link to some important articles here in a nice bullet list.
|
||||
|
||||
#### Branches
|
||||
|
||||
This is simple. Keep your branch names somewhat descriptive of what’s in them. GitHub automatically names your fixes after a patch if you edit them online, so whatever, but when you’re offline and you’re using git on your machine, give a nice, descriptive name to your branch that’s less than 30 characters.
|
||||
|
||||
[This git style guide](https://github.com/agis-/git-style-guide) says that **you should use “short and descriptive” names**, and I feel that’s a good benchmark for naming. Use something like “rails-5-upgrade” or use it to refer to a specific issue on GitHub, like “issue-57”. Make your branch name tell a story with as few characters as possible and give a _super_ quick synopsis of what you’re doing on it.
|
||||
|
||||
Also, for the love of Torvalds, **keep your branches up to date with the master branch**. I don’t care if it’s a pain to do. Make sure that when you submit a PR, the owner doesn’t have to go through a million hoops just to merge your branch to master. Merge conflict? Fix it.
|
||||
|
||||
#### Issues
|
||||
|
||||
Let’s talk bug reports for a moment here. Have you ever tried to fix something without knowing what the problem was in the first place? Huh? What’s, that, you say?
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/af1d6-19sx8dn-bz3srv-g1o0hlwg.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
That’s you. [That’s how dumb you sound.](https://www.youtube.com/watch?v=2nm5jl7aM08)
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
> You can’t possibly expect me to fix something without knowing what the problem was in the first place.
|
||||
|
||||
Exactly! So many people submit issue reports on GitHub without describing a damn thing. Be descriptive with your issues. It helps everyone out.
|
||||
|
||||
How do you honestly expect someone to help you out with your problem if you can’t even take the time to describe it? Here are some things you should include in a bug report to make everyone’s lives easier:
|
||||
|
||||
- **What you were trying to do.** What were the conditions that produced this error? Were you trying to run a command or navigate to a page? So many questions, so little time. Include some screenshots or a log, if you can.
|
||||
|
||||
- **What actually happened.** You know, how things messed up.
|
||||
|
||||
- **What you think went wrong (_optional_).** This screwed up somehow, right? Take a guess as to why.
|
||||
|
||||
- **How to reproduce your issue.**
|
||||
|
||||
- **Other _important_ details.** OS, Version of whatever you were using, some logs if you have them, some screenshots. Help us help you.
|
||||
|
||||
Now that we’ve got that out of the way, let’s talk about _replying_ to issues. Be nice. Say “please” and “thank you”. Just because someone submitted a bad issue doesn’t mean they’re a bad person. Being nice to people is the first step to getting them to cooperate. Try to solve their problem while asking for more information. Offer solutions, not more problems.
|
||||
|
||||
Project maintainers should probably use [issue templates](https://help.github.com/articles/creating-an-issue-template-for-your-repository/) on their projects with the above issue suggestions. They’re there for a reason. It’ll help your users make better issues and get you better bug reports/suggestions. Help them help you.
|
||||
|
||||
#### Pull Requests
|
||||
|
||||
Everyone likes a helping hand. Most of the time, though, people would like knowing _how_ you’re helping them. This applies to Pull Requests, too. By using your descriptive commit style and **adding a quick bullet list of the changes you made to their code**, you’ll catch the owner’s attention and make them want to merge your branch faster.
|
||||
|
||||
I mean, why am I going to add your code to my awesome project if I have no idea what it does? You don’t have to write an essay on why these changes are for the better, but at least **give a short description on why your code is going to benefit the project.**
|
||||
|
||||
Also, project maintainers. **_Thank your contributors_**_._ It’s a simple gesture that goes a long way. This person put time and effort into helping your project, and even if it was only one line of code, _thank them._ Doesn’t matter if their code is awful, thank them for the time that they took to help out with your project. [We’re all in this together](https://www.youtube.com/watch?v=gbrbUfYSt0E), right?
|
||||
|
||||
#### Now…
|
||||
|
||||
I’m betting you’re going to go to [my repos on GitHub](https://github.com/thattacoguy) and start [yelling at me on Twitter](https://twitter.com/that_taco_guy) about how I don’t follow my own guide. You’re right, I’m not right now; I wrote this up as a guide to follow to make better commits based on what seems to be hip and trendy now. Let’s get better together!
|
||||
|
||||
* * *
|
||||
|
||||
### If you really liked this post, be sure to click that little green heart so that others can find it!
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/755a8-1xs_n7ruqrbe-eszcs4oxrg.gif)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Just do it. You know you want to. ❤
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
After Width: | Height: | Size: 7.4 KiB |
After Width: | Height: | Size: 12 KiB |
After Width: | Height: | Size: 28 KiB |
After Width: | Height: | Size: 13 KiB |
After Width: | Height: | Size: 2.5 KiB |
After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 12 KiB |
After Width: | Height: | Size: 9.7 KiB |
After Width: | Height: | Size: 50 KiB |
After Width: | Height: | Size: 31 KiB |
After Width: | Height: | Size: 494 KiB |
|
@ -0,0 +1,218 @@
|
|||
---
|
||||
title: "[old] this is what you’re missing out on with continuous deployment"
|
||||
date: "2016-08-12"
|
||||
tags:
|
||||
- "continuous-integration"
|
||||
- "english"
|
||||
- "github"
|
||||
- "programming"
|
||||
- "tech"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from 2016.
|
||||
|
||||
![](images/dc0fc-1uuy2mvmyhb446qd5ovsg-a.png)
|
||||
|
||||
#### Ship it harder, better, faster, stronger
|
||||
|
||||
A few months ago, [Lennon](https://medium.com/u/57f86eb26cec) asked me to look into Continuous Deployment options for [devAcademy](https://medium.com/u/e90784f3811e). I got excited.
|
||||
|
||||
I had used a few CD platforms before with my _very_ short lived experience with setting up a server for a really obscure video g[a](https://github.com/TacoWolf/Canus)me. Most of the forks around there used Travis for their projects to make sure their builds would at least run, but I felt like there was more to continually integrating a project. I wanted to learn more, and now I had the opportunity to do so. Woo!
|
||||
|
||||
Now, you’re probably asking yourself,
|
||||
|
||||
> What can I do with Continuous Integration and Continuous Deployment?
|
||||
|
||||
#### **Here’s what I found out:**
|
||||
|
||||
### Robots test things so you don’t have to
|
||||
|
||||
You can use CD to run unit tests automatically. Our [website](https://devacademy.la), which runs on Rails, has a bunch of [RSpec](http://rspec.info/) tests that run, and all of those tests have to pass before any changes are accepted into the master branch.
|
||||
|
||||
Now, RSpec can be run by itself using [Guard](https://github.com/guard/guard-rspec), but I’ve never had any success with it, personally. This means **we have to run tests ourselves locally before we commit to make sure our code works**.
|
||||
|
||||
You know how many times we forget to run our tests?
|
||||
|
||||
> **Every. Single. Time.**
|
||||
|
||||
How do we fix this? **Automate it!**
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/4c504-1jxzwvlfmv0kn5ar_v1ax9a.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
this feels so satisfying to look at
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
> **By using a Continuous Integration platform, we can make sure that each commit we make passes all of our tests**.
|
||||
|
||||
Once a commit is pushed to our GitHub repos, our CI/CD platform grabs the latest copy and starts to run commands based on our configuration file in the repository, which is super easy to configure. Once the command goes green, you can ship it! Super simple stuff.
|
||||
|
||||
We also have Simplecov to check our code coverage, which runs right alongside our RSpec tests. That means that when we run a build, we also get a percentage of how much code we’re actually testing.
|
||||
|
||||
![](images/22a3c-1jidr3-zogqapfumc0ltmq.png)
|
||||
|
||||
Real neat-o.
|
||||
|
||||
### Robots check things so you don’t have to
|
||||
|
||||
> **You can use a CI/CD platform to check your code automatically.**
|
||||
|
||||
The previously mentioned Rails app we maintain every day has to have some sort of rigorous standard so that our code continues to be awesome. We use [Rubocop](https://github.com/bbatsov/rubocop) to make sure that we follow the [Ruby style guide made by the community](https://github.com/bbatsov/ruby-style-guide) in all of our Ruby/Rails projects.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/5c6f2-0bebwajr462xoi5of.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
“Role models are important.” — Robocop
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
As I mentioned earlier, we have to run our tests manually on our end, and sometimes we forget. With Rubocop, it’s the same. We forget to check our code _often_. This sometimes leads to us committing things that aren’t in line with the rest of our code, which is bad.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/7bef4-1ycdnl3s6-wszvumig5mxwq.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
aesthetically pleasing
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
Luckily, we’ve set up our CI/CD platform to run Rubocop right after RSpec. If something isn’t up to standard, the build fails, and we don’t ship it until it’s fixed. It’s a great way of making sure you write awesome code.
|
||||
|
||||
### Robots tell you that you messed up (so you don’t have to)
|
||||
|
||||
So, let’s say you get your CI/CD provider setup. Issue is, you have to wait for every build to pass, and that wastes time… you have other things you need to be doing instead, right? You look away and you forget about the build failing… and you think to yourself,
|
||||
|
||||
> “Wouldn’t it be great if I could receive notifications for my builds in the chat client I’m using so I can continue working without having to worry about checking on it?”
|
||||
|
||||
#### _WELL, DO I HAVE SOME GOOD NEWS FOR YOU._
|
||||
|
||||
A _lot_ of CI/CD providers I’ve seen these days have integrations for Slack ([which you should be using, if you didn’t know](https://stories.devacademy.la/why-slack-is-the-best-chat-platform-for-your-team-a13cd07881#.aib4m24zn)).
|
||||
|
||||
In our Slack team we get messages when our builds have completed. These can either be passing… or failing. When our builds fail, we normally laugh at each other about it:
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/984e9-1l0cajknakdfkovy_pssrww.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
#Mal[Kattya](https://medium.com/u/7cd86522af8d)
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
…And when our build passes, we congratulate each other for fixing it!
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/48f0a-11axerx_-slkjx8ygcfnllg.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
#Bien[Kattya](https://medium.com/u/7cd86522af8d)
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
This helps us know the state of all of our projects without having to leave Slack, and lets us know our personal progress. Since all the build logs are shared in our team, we can help each other out, too!
|
||||
|
||||
### Robots ship it automatically
|
||||
|
||||
We use Heroku for our apps. We used to deploy our application every time we made a new commit to master, and that got really boring really quickly. We couldn’t just push code immediately to production, we had to test it out manually.
|
||||
|
||||
So, guess what we did after we added all of the other cool continuous deployment stuff?
|
||||
|
||||
We turned this on:
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/9764d-14jwe6bqkw5xiphtdazpepa.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
What’s this button do?
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
One thing to note is the “Wait for CI to pass before deploy” option. This makes sure that our production app always has working tests and is always up to standard, because it checks that our CD build passed.
|
||||
|
||||
Awesome, right?
|
||||
|
||||
We use GitHub for all of our repos, and most CD providers have some sort of native GitHub support. Most providers even allow you to see if your build is green or not _right in GitHub itself_.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/0e4cf-1lbgthzommycrd4nolfyngw.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Ridiculously cool.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
### “So, how do I get started?”
|
||||
|
||||
We recommend using [Travis CI](https://travis-ci.org). It isn’t the only option out there, but it’s one we use all the time and recommend fully. It’s a great place to get familiar with automating tests and code checks. Setup is as easy as pushing a YAML file to your repo. Best of all, it’s free for open source projects.
|
||||
|
||||
Travis CI isn’t the only hosted service out there. Here’s a few others:
|
||||
|
||||
- [Codeship](https://codeship.com/)
|
||||
|
||||
- [Circle CI](http://circleci.com/)
|
||||
|
||||
- [AppVeyor](https://www.appveyor.com/)
|
||||
|
||||
What’s most important is that you get something that’s right for you. CI/CD is essential to coding these days. Why?
|
||||
|
||||
> Continually deploying your code into production helps push features out faster and gets work done quicker, which makes everyone happier.
|
||||
|
||||
No more waiting to check if your code works or any other tests you need to do. Once you automate everything once and get it working right, you have less things to worry about in general.
|
||||
|
||||
That’s more time for you sit back, relax, and take it easy.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/24746-0bg6y9lt7jobrkjqr.jpg)
|
||||
|
||||
<figcaption>
|
||||
|
||||
“I’ll ship it tomorrow…”
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
Pretty cool, right?
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/4ae54-18x4u4q_avsogffnughqkaa.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Just do it. You know you want to. ❤
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
After Width: | Height: | Size: 77 KiB |
After Width: | Height: | Size: 28 KiB |
After Width: | Height: | Size: 9.4 KiB |
After Width: | Height: | Size: 24 KiB |
126
content/posts/old/whitespace/index.md
Normal file
|
@ -0,0 +1,126 @@
|
|||
---
|
||||
title: "[old] whitespace"
|
||||
date: "2016-12-25"
|
||||
tags:
|
||||
- "design"
|
||||
- "english"
|
||||
- "productivity"
|
||||
- "tech"
|
||||
- "ux"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from 2016.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/3eb8c-1uxxgsmvhhtuz50vtk9t11g.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
breathe.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
#### Because everyone needs to breathe.
|
||||
|
||||
Everyone has experienced stress in their lives in some way or another. For most people, the easiest ways to relieve some sort of stress in their lives is to take a break and step away from any information for awhile.
|
||||
|
||||
One of the genius innovations in design that’s gotten popular lately is one I’m real glad that exists today:
|
||||
|
||||
> Whitespace.
|
||||
|
||||
Believe it or not, you experienced whitespace. The simple action of separating text using a new line to let one word take the center stage makes a difference.
|
||||
|
||||
#### What is it, really?
|
||||
|
||||
Whitespace can be defined as space where there is nothing — empty space. It’s a separation between your sections of content and the borders of the viewport you’re displaying things on. It allows for specific images or words to stand out because they’re separated from the rest of the content. Users can specifically focus on one piece of information.
|
||||
|
||||
[Gisele Muller](https://medium.com/u/6b4913453525) [describes it well:](http://blog.teamtreehouse.com/white-space-in-web-design-what-it-is-and-why-you-should-use-it)
|
||||
|
||||
> “It’s the space between graphics, columns, images, text, margins and other elements. It is the space left untouched in order to smooth things out and transform a page into something elegant. It is also the blank space that reminds us that simpler designs are beautiful and that we don’t need to create a layout filled with text and graphical elements to deliver a clear and direct message.”
|
||||
|
||||
#### But… why?
|
||||
|
||||
Information is important, but you can’t expect someone to consume whole paragraphs of information in seconds. Structuring information in a way that users can digest each snippet of information. That’s the key element to using whitespace.
|
||||
|
||||
![](images/28fe9-1dwr6l_fjhnnuo1wf-jgehq.jpeg)
|
||||
|
||||
Users need to understand what your message is at a first glance. If someone viewing your app or website can’t understand the meaning behind your site quickly, they will leave. Closing a web page or app is the easiest way to avoid confusing things that users [don’t have time for](https://www.youtube.com/watch?v=bFEoMO0pc7k).
|
||||
|
||||
> If someone viewing your app or website can’t understand the meaning behind your site quickly, they will leave.
|
||||
|
||||
Users don’t care much about the flowery prose that your message is contained in, rather the actual message itself. Modern designs for websites only focus on images and quick phrases, or only display words that convey what the focus of your project is about.
|
||||
|
||||
Your focus should be on making sure that the core idea behind your content hooks the user in to consider looking at the rest of the page. If you have space that allows for information to be presented in bite-sized portions, users will remember you better. Key words and phrases are what users are going to know you by, not specific details. It’s how our brain stores information. Cut out the middleman and filter out unnecessary words and sentences.
|
||||
|
||||
#### Whitespace in web design
|
||||
|
||||
Google is probably my favorite example of whitespace in modern designs.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/16199-1b-ujsexdgbc2-os7we2g.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Yeah, Quechua. I was surprised, too.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
Google’s front page gives you a limited amount of options to work with so that you don’t get confused. The whole website is centered around searching things, and your focus is centered on the content in the middle. The gentle shadow behind the search bar lets you know that it’s more important than the other elements.
|
||||
|
||||
The two buttons you’re immediately given access to ease you into the design — you have power over what you do! You can search for many options or try your luck and go to the first result for your query.
|
||||
|
||||
This way of spreading out the options you have lets you analyze what you need when you need it. Nothing is intruding your vision or forcing you to squint to read anything. You have enough time and ample room to digest what’s being presented to you. It feels natural to use Google’s search engine because there’s little guesswork in what you can and cannot do. Everything is spaced out and there’s never a place where content feels crowded.
|
||||
|
||||
#### Whitespace in programming
|
||||
|
||||
Whitespace isn’t only limited to design. Utilizing whitespace in your code is important. Your code should be legible and spaced. The fact that it could be a project that never sees the light of day is irrelevant. Your code should make sense and nested functions should have proper spacing.
|
||||
|
||||
Everyone has differing opinions on whether to use tabs, 4 spaces, 2 spaces or any other combination of separation of characters. I use 2 spaces in my projects, but that’s my personal preference. What does matter is that you use spacing to make your code stand out and appear readable to other people.
|
||||
|
||||
Take a look at this HTML code:
|
||||
|
||||
```
|
||||
<!DOCTYPE html><html lang=”en”><head><meta charset=”UTF-8"><title>This is an HTML document!</title></head><body><div class=”row”><div class=”col m5">Some content<div class=”row”><div class=”col s12">Some nested content</div></div></div><div class=”col m5">Some other content (woah)</div><div class=”col m2">Even MORE content</div></div></body></html>
|
||||
```
|
||||
|
||||
Yes, it’s an HTML document, but there’s no real implication of what goes where. Everything seems like it’s on the same level. Tags could appear nested, but you’re not sure which one does which. Someone else might not want to touch this — they’ll be worried they’ll break something in the layout. Applying some whitespace to this code demonstrates the following:
|
||||
|
||||
```
|
||||
<!DOCTYPE html><html lang="en">
|
||||
```
|
||||
|
||||
```
|
||||
<head> <meta charset="UTF-8"> <title>This is an HTML document!</title></head>
|
||||
```
|
||||
|
||||
```
|
||||
<body> <div class="row"> <div class="col m5"> Some content <div class="row"> <div class="col s12"> Some nested content </div> </div> </div> <div class="col m5"> Some other content (woah) </div> <div class="col m2"> Even MORE content </div> </div></body>
|
||||
```
|
||||
|
||||
```
|
||||
</html>
|
||||
```
|
||||
|
||||
Woah! There was a whole collection of divs that had nested content hidden in our non-whitespaced code! Storing the code this way makes it so that other people working on this static HTML page know how the page is really structured. It makes it so that people aren’t intimidated to dive in and help out with changing details in code. (also it’s common human decency)
|
||||
|
||||
This doesn’t just apply to HTML. This applies to practically any programming language out there (except the [esoteric ones](https://en.wikipedia.org/wiki/Whitespace_%28programming_language%29)). Most languages have some sort of “beautifier” or “prettifier” to make your code seem legible and spaced out.
|
||||
|
||||
Knowing what lines of code are on the same level and what variables are accessible where is important in the long run. When you’ve got 100+ files of code and hundreds of functions, you need to be able to parse your code easier. A simple glance should be all it should take to know where a variable or function is located in relation to everything else.
|
||||
|
||||
#### Whitespace in your life
|
||||
|
||||
[Jason Fried](https://medium.com/u/c030228809f2) mentions in many of his posts that Basecamp, as a company, strongly encourages its employees to only work 40 hours a week. He also mentions that taking a few hours a day to yourself is important. [Jon Westenberg](https://medium.com/u/5ce28105ffbc) also mentions that you should “[slow the fuck down](https://medium.com/hi-my-name-is-jon/you-are-more-than-your-productivity-slow-the-fuck-down-6ed7c4be3fcc#.k88geuntv)” and take life one step at a time.
|
||||
|
||||
![](images/b8119-1crpi63tfn5be16doo9my5w.jpeg)
|
||||
|
||||
In today’s bustle of constant information, sometimes we forget to take some time for ourselves. It doesn’t matter how many hours of work you do in a day, the final product matters. The quality of a product is more important than the time it took to make it. This time to generate a quality product is different for everyone.
|
||||
|
||||
Take some extended periods of time to do something that relaxes you. I normally take time to myself to play some games or catch up on reading Medium articles. Everyone’s ways of relaxing are different, but make sure you make whitespaces in between the hustle and bustle of the day to breathe.
|
||||
|
||||
You deserve it.
|
After Width: | Height: | Size: 9.6 KiB |
After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 163 KiB |
After Width: | Height: | Size: 15 KiB |
After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 25 KiB |
After Width: | Height: | Size: 91 KiB |
After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 16 KiB |
After Width: | Height: | Size: 88 KiB |
After Width: | Height: | Size: 10 KiB |
|
@ -0,0 +1,212 @@
|
|||
---
|
||||
title: "[old] why slack is the best chat platform for your team"
|
||||
date: "2016-07-22"
|
||||
tags:
|
||||
- "communication"
|
||||
- "english"
|
||||
- "slack"
|
||||
- "startup"
|
||||
- "team"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from 2016.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/f1721-1sppqsgpviugqzv4n1bpnsq.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
These symbols, what could they mean
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
#### And why we use it so much
|
||||
|
||||
It’s no secret we use [Slack](https://medium.com/u/26d90a99f605) here at [devAcademy](https://medium.com/u/e90784f3811e). In fact, we _want_ you to know we use Slack. It’s an indispensable tool for our team, since we need to communicate on the go, wherever we are. Honestly, I don’t think we would even be as productive as we are without Slack and the awesome community behind it. Here are the reasons why we love it so much. ❤
|
||||
|
||||
#### An instant message is worth a thousand spoken words
|
||||
|
||||
> Slack helps us communicate better.
|
||||
|
||||
Even though at times we’re two feet away from each other at devHouse, we chat constantly. There are ways to specifically emphasize your words so your meaning isn’t lost, especially with the Markdown support Slack has.
|
||||
|
||||
Some people will argue that instant messaging tears people apart. Simple text on a screen can’t convey the same amount of information that spoken word can. They have a point — it can’t. But what instant messaging gives us is a way to express ideas and communicate with people halfway across the world within seconds. A skilled instant message user can both send and receive messages that convey just the right amount of feeling and emotion to incite a response.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/6074f-1j9z-bjp7bhirfqnuj_gvhw.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
See? Emphasis.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
For people like me, who are growing up in the age of instant message platforms, we prefer instant messaging to normal speech. Why? It helps us speak when our physical voices aren’t enough. Platforms like Twitter, Facebook and _\[coughs\]_ Medium are giving people who didn’t have a voice before a place to share ideas and grow their own community.
|
||||
|
||||
> Your company needs their own internal social network to share their ideas and feel empowered within their group of peers.
|
||||
|
||||
This is where Slack steps in. By using Slack, your company can have a better sense of unity and a more equal sense of communication. No formal company letters. No dumb corporate meetings. No tedious emails. Just chat with your coworkers. Send a funny joke to your boss. Chat about something you need help with in a public channel. Relax.
|
||||
|
||||
Work can be fun, right?
|
||||
|
||||
#### Smile for the chat log
|
||||
|
||||
> Slack helps grow company culture.
|
||||
|
||||
Slack helps us grow our company’s culture by providing a fun environment for us to interact in without having to sound too formal. Slack even provides you with a **#random** channel by default. This helps promote a lighthearted communication environment for teams, giving you an incentive to share that funny cat video you found to put a smile on your team member’s faces.
|
||||
|
||||
Slack can help you interact with your team in a fun, enjoyable way instead of sounding like corporate robots all the time. Fun quips and a joyful chat log help promote a happy company workflow. I’m not too sure about the technical business jargon behind all of that, but I think we can all agree that it’s pretty important.
|
||||
|
||||
https://twitter.com/that\_taco\_guy/status/747582258148745216
|
||||
|
||||
After reading this, you should look at [this great article](https://medium.com/@j_henches/how-to-turn-followers-into-die-hard-fans-try-sounding-like-a-human-38ca164e8973#.3rmzews28) by [Julie Henches](https://medium.com/u/593ab75f38f5). She says something which is really nails what we’re all about at [devAcademy](https://medium.com/u/e90784f3811e):
|
||||
|
||||
> Are you a robot? If not, don’t make yourself sound like one.
|
||||
|
||||
Your company should really apply this in every aspect, not just marketing. Sounding like a robot in today’s day and age doesn’t cut it, and I’m 100% sure that your team members _hate_ being treated like another piece of a puzzle instead of an actual human being. Your team needs to be sold on the idea that your company isn’t a set of trademarks and legal documents — it’s a living, breathing entity that they want to be a part of. Slack helps us out with this by providing a comfortable, secure environment to talk about anything. You can mention someone, send them something and get instant feedback in an organized, natural and organic way.
|
||||
|
||||
#### Sharing information in the instant messaging age
|
||||
|
||||
> Slack helps you share information.
|
||||
|
||||
This probably sounds silly to you. Of _course_ you share information through chat messages. Isn’t that the whole point? But when you take a moment to step back and really take a look at how Slack and other instant messaging platforms work, you get to really see the big picture behind it all. Each message you send is data that can be searched through and looked up with a few keystrokes. Anything shared in a message can be starred in Slack, so you can look it up for later use.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/46342-1p6gbujpr8ua3apmkc-ylpw.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
I should check this out later…
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
If you’re as busy as we are, it’s much easier to write something down where you can be reminded of it later instead of listening to a whole bunch of people yap at you all at once. It’s where instant messaging really shines — many people can be talking at once without having to pause or slow down. Messages can be as long or as short as you’d like, and you can have long, meaningful discussions that can be interactive and not just one sided. Slack makes this experience fun and exciting by adding reactions to your posts. This makes everything more lighthearted by letting everyone know your feelings on what you said.
|
||||
|
||||
These can either be positive…
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/f7364-12ttsipwkypoagxgd4vl_mw.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Congrats, [Lennon](https://medium.com/u/57f86eb26cec)!
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
…or negative…
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/942ed-1g21jncath2jou4lzsfzx8g.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Get your head in the game, [victor](https://medium.com/u/97ee2c25d230).
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
…or somewhere in between.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/a1fff-1v3m4ymtdgspt_uutrvwwla.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
We’re all confused as to how [Giancarlos](https://medium.com/u/69cefb0fedff) doesn’t play Guitar Hero.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
You can even add your own emojis, which is pretty awesome.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/0d4f9-1czcbts6439ovbpnoxq6dtq.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Have something to tell us, [Kattya](https://medium.com/u/7cd86522af8d)?
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
#### Anytime, anywhere
|
||||
|
||||
> Slack is available whenever and wherever you are.
|
||||
|
||||
Do you have access to a web browser? You can use Slack. Their native apps are also pretty awesome, and their design guidelines make sure that you can keep up with what’s happening even if you’re on a smartphone, a laptop or your desktop computer. I’m pretty sure if I shoved a Raspberry Pi into a toaster, I’d be able to open Slack on it.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/3b7b9-1urpwggrsjr17scdxmbzqlw.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
:v
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
I’m going to gush like a design nerd for a moment, though. Slack’s UI is gorgeous. Their slick, smooth design makes me want to use their chat service forever. Another thing? Functionality. All of their apps make sure that you never feel left out on any features on any device. I’ve never had to say “I’ll have to wait until I get on a different device to do this” — I can just do it. That’s an amazing thing to be able to say. I haven’t found something in Slack that I didn’t like, and I’m pretty picky!
|
||||
|
||||
#### I heard you like apps, so we put an app in your app so you can do things while you do things
|
||||
|
||||
> Slack provides you with a wide variety of integrated apps.
|
||||
|
||||
Now, Slack can’t provide you with absolutely everything. There are some things that they’re just not good at. They’re busy working on making their own chat platform better and can’t possibly add all the specific things you’d like just for your team. How do they solve this problem, though? Integrations.
|
||||
|
||||
[Integrations](https://slack.com/apps) are like little mini-apps inside of Slack that run without having to install anything on your machine. They can do a whole bunch of stuff straight from Slack without having to switch tabs, which is super useful and gives your team a sense of transparency.
|
||||
|
||||
You say you’re going to make a card on Trello to remind yourself to upgrade the platform to Rails 5? [There’s a Slack app for that.](https://slack.com/apps/A074YH40Z-trello)
|
||||
|
||||
![](images/743ae-1hlggolcdw_znedgi0ggbka.png)
|
||||
|
||||
You want to know what’s happening on your GitHub repositories without having to tab over to GitHub itself? [There’s a Slack app for that, too.](https://slack.com/apps/A0F7YS2SX-github)
|
||||
|
||||
![](images/28572-1allrtgnpiuozf3e8d6vpfw.png)
|
||||
|
||||
Sometimes, though, you’ll find that there’s some functionality that you can’t seem to achieve with a simple integration install. Slack has that covered for you, too. [Slack’s API](https://api.slack.com/) is simple to use and there’s a few great existing libraries that let you create your own awesome integrations for Slack. We’re working on [PiscoBot](https://github.com/devacademyla/PiscoBot) here at devAcademy as our own homegrown custom integration, and it’s a lot of fun! It helps us create our own organic company environment in what could be an otherwise bland chat room.
|
||||
|
||||
(You can read more about why we think bots are amazing [here](https://medium.com/devacademy-stories/you-need-a-chat-bot-right-now-and-heres-why-cbbe5a69367e#.7i2z40upt).)
|
||||
|
||||
#### Long story short…
|
||||
|
||||
> Slack is great. You should use it. It gives you the tools you need to make a good team a great team.
|
||||
|
||||
Now go out and make something awesome.
|
||||
|
||||
_(_**_Note_**_: These are entirely my own opinions. I wasn’t paid by Slack to advertise their product but hey a few dollars coming my way wouldn’t be bad, so hit me up,_ [_Slack_](https://medium.com/u/26d90a99f605)_. But seriously, though, Slack is great.)_
|
||||
|
||||
* * *
|
||||
|
||||
Don’t forget to recommend this post to others if you enjoyed it. ❤
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/755a8-1xs_n7ruqrbe-eszcs4oxrg.gif)
|
||||
|
||||
<figcaption>
|
||||
|
||||
help a brother out
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
After Width: | Height: | Size: 36 KiB |
|
@ -0,0 +1,72 @@
|
|||
---
|
||||
title: "[old] why working remotely is really awesome"
|
||||
date: "2016-07-12"
|
||||
tags:
|
||||
- "culture"
|
||||
- "productivity"
|
||||
- "remote-working"
|
||||
- "startup"
|
||||
- "team"
|
||||
---
|
||||
|
||||
#### And why it kinda sucks
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from 2016.
|
||||
>
|
||||
> i no longer work for devacademy, and i think they dissolved in 2019?
|
||||
|
||||
I’ve been working at [devAcademy](https://devacademy.la/) since December. I’m not going to lie, I love working for dev. I’ll swear up and down that I enjoy making things for and with the company. It’s not because of all the cool benefits I’m getting from working with them or the paycheck.
|
||||
|
||||
> It’s because I’m part of a team.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/7a4d2-123eiosnd_e6ajoegm2hg2g.jpeg)
|
||||
|
||||
<figcaption>
|
||||
|
||||
This is supposed to be an image related to working remotely, right? I’m not good at marketing.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
#### A long, long time ago, in a college far, far away…
|
||||
|
||||
I met [Lennon Shimokawa](https://medium.com/u/57f86eb26cec) while he was giving a Rails course at my college. I was pretty stoked about learning more about devAcademy when he gave us the hands on course.
|
||||
|
||||
Why? He spoke my language.
|
||||
|
||||
> Most of us here at dev speak the same language: **fluent computer nerd.**
|
||||
|
||||
We all talk about open source projects we like and how we can make devAcademy better by sharing dumb, nerdy ideas together.
|
||||
|
||||
An indispensable tool that has helped us in all of our communication is [Slack](https://slack.com/). I could probably write an entire post about Slack (and I probably will). It’s one of the best tools for any team, ever. Even if people on our team are less than 5 feet away from each other, they’ll chat through Slack. Why? Slack helps us generate a company culture that’s not only inside of the office, but reaches to a wider range of people. We use little tools like [Hey Taco!](https://medium.com/u/32fafd911287) and [HowdyAI](https://howdy.ai) to enhance our happiness and productivity.
|
||||
|
||||
#### A global reach for a local company
|
||||
|
||||
We also use tools like GitHub, Hubstaff and Trello to make sure we have accountability, reliability and a global reach when it comes to using agile development methodologies. It really helps people like me who aren’t there physically to see what’s going on. All of our code stays on GitHub and we make sure to work with our Trello cards religiously so that absolutely everyone is on the same page. If I want to see what people are working on, I don’t have to waste their time asking them, I can just take a gander at the Trello board and know what’s going on in minutes.
|
||||
|
||||
I’m not going to lie and say everything is perfect. Not being in person at my job feels kind of lonely sometimes. Not everyone is on Slack all the time, and we all have our personal lives at the end of the day. I also have weird, erratic work times due to me studying full time, and that doesn’t help much. Some concepts and phrases are lost in translation. But even through all of that, I don’t feel like I’m alienated even though [I’m a thousand miles away from our office in Ica](https://www.google.com.ec/maps/dir/ITSAE-CADE/devAcademy,+Eucaliptos,+Ica,+Peru/@-6.7283223,-81.5527133,6z/data=!4m13!4m12!1m5!1m1!1s0x91d536e05e4dd017:0x32ef7dc0d58dc330!2m2!1d-79.2477385!2d-0.3485003!1m5!1m1!1s0x9110e2d62ddfd3c9:0xe6508f6de22f8bc8!2m2!1d-75.749372!2d-14.046913?hl=en). It’s why we even use Slack in the first place.
|
||||
|
||||
> At devAcademy we think globally, instead of just having our goals on our own local market.
|
||||
|
||||
Using tools that have a wider reach and that are easily scalable lets our company grow easily and help us reach a wider audience.
|
||||
|
||||
I worked for devAcademy for two months before I saw Lennon again in person. By then I felt like I was a part of something bigger — something I could be proud of and tell everyone I know about happily.
|
||||
|
||||
When I visited devHouse in February, I didn’t felt like I was stepping into an alien office environment with people I didn’t know.
|
||||
|
||||
<figure>
|
||||
|
||||
![](https://cdn-images-1.medium.com/max/800/0*LXdUE_xPCmsjq9tD.)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Take a wild guess as to who I am
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
> I felt like I was at home.
|
After Width: | Height: | Size: 43 KiB |
After Width: | Height: | Size: 26 KiB |
After Width: | Height: | Size: 65 KiB |
|
@ -0,0 +1,76 @@
|
|||
---
|
||||
title: "[old] you need a chat bot right now, and here’s why"
|
||||
date: "2016-07-05"
|
||||
tags:
|
||||
- "bots"
|
||||
- "chatbots"
|
||||
- "communication"
|
||||
- "messaging"
|
||||
- "programming"
|
||||
---
|
||||
|
||||
> **disclaimer:** this post is really old, from when i first started writing technical articles. it's from 2016.
|
||||
|
||||
Let’s be real for a second here… I _love_ conveniently automated things. I love when programs work for me instead of having to set them up (or beat them into submission). When great ideas and great code work hand in hand, they make great software that just _works_. One of the greatest ideas that’s come out recently is using software through a chat interface, or as you probably know them, **chat bots.**
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/88ad3-0uj0w1imzdpa0onpb.jpg)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Photo credit: [jeffedoe](https://www.flickr.com/photos/jeffedoe/506027963/) / [CC BY-ND](http://creativecommons.org/licenses/by-nd/2.0/)
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
#### I, for one, welcome our new talkative overlords
|
||||
|
||||
We here at dev are pretty certain that chat bots are the future, and we’re not the only ones that do.
|
||||
|
||||
> Chat apps will come to be thought of as the new browsers; bots will be the new websites. This is the beginning of a new internet.
|
||||
|
||||
- [Ted Livingston](https://medium.com/u/2d041e2f8c3), [The Future of Chat Isn’t AI](https://medium.com/@tedlivingston/the-future-of-chat-isn-t-ai-b07f65bc252)
|
||||
|
||||
The people at [Kik](https://medium.com/@tedlivingston/the-future-of-chat-isn-t-ai-b07f65bc252#.wbcdlnljn), [Facebook](https://developers.facebook.com/docs/messenger-platform), [Slack](https://api.slack.com/bot-users), [Discord](https://discordapp.com/developers/docs/intro) and even [Skype](https://developer.microsoft.com/en-us/skype/bots) know that the people want chat bots. It’s one of the biggest untapped markets, since we all use IMs to communicate with each other these days. Being able to do things directly in chat is a must-have for any company these days.
|
||||
|
||||
End Users love having work done for them. We don’t like to move to other places to do things. We might as well not do them if we have to click on something. Having a place where you can do just about anything through chat bots is a reason to stay there and chat. A bot won’t judge or challenge you. It does whatever it’s made to do, and hopefully does it well.
|
||||
|
||||
#### So, what are we doing about it?
|
||||
|
||||
We’re are currently working on rewriting a bot I made for our Slack team here at devAcademy called [PiscoBot](https://github.com/devacademyla/piscobot). Creating an accessible user interface through chat sounds hard, but it’s actually pretty easy (and _definitely_ worth it).
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/1eb4c-167zvqsrqjpksiotefydvga.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
We also give out shots of Pisco as a reward
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
For example, we have a command in PiscoBot allow us to check who’s worked the most on Hubstaff. It’s a conversation starter! Your can use bot replies as an icebreaker to talk about any topic you want. We use it to discuss how many hours our team is working and how we can coordinate our working hours better.
|
||||
|
||||
Being able to search for a Pokémon directly in chat isn’t a dumb, silly feature. It actually helps strengthen and grow an otherwise stale and disconnected community. By being able to share common interests and make communication easier and more friendly, your team will grow naturally. Be it at your workplace, with your group of friends or even with your family, chat bots can help you more than you can imagine.
|
||||
|
||||
<figure>
|
||||
|
||||
![](images/0e015-1nx3eb5lbb5bzxekqpvwp7w.png)
|
||||
|
||||
<figcaption>
|
||||
|
||||
Using a Magic 8 Ball digitally is much easier than using one IRL.
|
||||
|
||||
</figcaption>
|
||||
|
||||
</figure>
|
||||
|
||||
If you use Slack, there’s our own home grown [PiscoBot](http://github.com/devacademyla/piscobot), which is open source. There’s also other bots that are easy to set up and maintain, like Hubot, by GitHub themselves. Test some out, and find one that’s best for your team!
|
||||
|
||||
You could even make one yourself! For Slack, Twilio and Facebook there’s the awesome [Botkit](https://github.com/howdyai/botkit) for NodeJS, which was made with Slack in mind. It has pretty neat conversation code which allows you to make your own bot _very_ easily. There’s loads of other libraries out there for making your own bot user, so find which one is best for you!
|
||||
|
||||
We here at dev wholeheartedly recommend setting up a chat bot for your team or community, wherever you are. It’s helped us grow a lot; not only as a workplace, but as a community. We’re pretty sure it can help you, too.
|
9
themes/corazon/content/_index.md
Normal file
|
@ -0,0 +1,9 @@
|
|||
+++
|
||||
title = 'Home'
|
||||
date = 2023-01-01T08:00:00-07:00
|
||||
draft = false
|
||||
+++
|
||||
|
||||
Laborum voluptate pariatur ex culpa magna nostrud est incididunt fugiat
|
||||
pariatur do dolor ipsum enim. Consequat tempor do dolor eu. Non id id anim anim
|
||||
excepteur excepteur pariatur nostrud qui irure ullamco.
|
7
themes/corazon/content/posts/_index.md
Normal file
|
@ -0,0 +1,7 @@
|
|||
+++
|
||||
title = 'Posts'
|
||||
date = 2023-01-01T08:30:00-07:00
|
||||
draft = false
|
||||
+++
|
||||
|
||||
Tempor est exercitation ad qui pariatur quis adipisicing aliquip nisi ea consequat ipsum occaecat. Nostrud consequat ullamco laboris fugiat esse esse adipisicing velit laborum ipsum incididunt ut enim. Dolor pariatur nulla quis fugiat dolore excepteur. Aliquip ad quis aliqua enim do consequat.
|
10
themes/corazon/content/posts/post-1.md
Normal file
|
@ -0,0 +1,10 @@
|
|||
+++
|
||||
title = 'Post 1'
|
||||
date = 2023-01-15T09:00:00-07:00
|
||||
draft = false
|
||||
tags = ['red']
|
||||
+++
|
||||
|
||||
Tempor proident minim aliquip reprehenderit dolor et ad anim Lorem duis sint eiusmod. Labore ut ea duis dolor. Incididunt consectetur proident qui occaecat incididunt do nisi Lorem. Tempor do laborum elit laboris excepteur eiusmod do. Eiusmod nisi excepteur ut amet pariatur adipisicing Lorem.
|
||||
|
||||
Occaecat nulla excepteur dolore excepteur duis eiusmod ullamco officia anim in voluptate ea occaecat officia. Cillum sint esse velit ea officia minim fugiat. Elit ea esse id aliquip pariatur cupidatat id duis minim incididunt ea ea. Anim ut duis sunt nisi. Culpa cillum sit voluptate voluptate eiusmod dolor. Enim nisi Lorem ipsum irure est excepteur voluptate eu in enim nisi. Nostrud ipsum Lorem anim sint labore consequat do.
|
10
themes/corazon/content/posts/post-2.md
Normal file
|
@ -0,0 +1,10 @@
|
|||
+++
|
||||
title = 'Post 2'
|
||||
date = 2023-02-15T10:00:00-07:00
|
||||
draft = false
|
||||
tags = ['red','green']
|
||||
+++
|
||||
|
||||
Anim eiusmod irure incididunt sint cupidatat. Incididunt irure irure irure nisi ipsum do ut quis fugiat consectetur proident cupidatat incididunt cillum. Dolore voluptate occaecat qui mollit laborum ullamco et. Ipsum laboris officia anim laboris culpa eiusmod ex magna ex cupidatat anim ipsum aute. Mollit aliquip occaecat qui sunt velit ut cupidatat reprehenderit enim sunt laborum. Velit veniam in officia nulla adipisicing ut duis officia.
|
||||
|
||||
Exercitation voluptate irure in irure tempor mollit Lorem nostrud ad officia. Velit id fugiat occaecat do tempor. Sit officia Lorem aliquip eu deserunt consectetur. Aute proident deserunt in nulla aliquip dolore ipsum Lorem ut cupidatat consectetur sit sint laborum. Esse cupidatat sit sint sunt tempor exercitation deserunt. Labore dolor duis laborum est do nisi ut veniam dolor et nostrud nostrud.
|
BIN
themes/corazon/content/posts/post-3/bryce-canyon.jpg
Normal file
After Width: | Height: | Size: 19 KiB |
12
themes/corazon/content/posts/post-3/index.md
Normal file
|
@ -0,0 +1,12 @@
|
|||
+++
|
||||
title = 'Post 3'
|
||||
date = 2023-03-15T11:00:00-07:00
|
||||
draft = false
|
||||
tags = ['red','green','blue']
|
||||
+++
|
||||
|
||||
Occaecat aliqua consequat laborum ut ex aute aliqua culpa quis irure esse magna dolore quis. Proident fugiat labore eu laboris officia Lorem enim. Ipsum occaecat cillum ut tempor id sint aliqua incididunt nisi incididunt reprehenderit. Voluptate ad minim sint est aute aliquip esse occaecat tempor officia qui sunt. Aute ex ipsum id ut in est velit est laborum incididunt. Aliqua qui id do esse sunt eiusmod id deserunt eu nostrud aute sit ipsum. Deserunt esse cillum Lorem non magna adipisicing mollit amet consequat.
|
||||
|
||||
![Bryce Canyon National Park](bryce-canyon.jpg)
|
||||
|
||||
Sit excepteur do velit veniam mollit in nostrud laboris incididunt ea. Amet eu cillum ut reprehenderit culpa aliquip labore laborum amet sit sit duis. Laborum id proident nostrud dolore laborum reprehenderit quis mollit nulla amet veniam officia id id. Aliquip in deserunt qui magna duis qui pariatur officia sunt deserunt.
|
|
@ -1 +1 @@
|
|||
<p><a rel="noreferrer noopener" href="https://mestizo.monster" target="_blank">mestizo.monster</a> © current year by <a rel="noreferrer noopener" href="https://mestizo.monster/about" target="_blank">taco</a> is licensed under <a rel="noreferrer noopener" href="http://creativecommons.org/licenses/by-nc/4.0/?ref=chooser-v1" target="_blank">CC BY-NC 4.0</a>.</p>
|
||||
<p>Copyright {{ now.Year }}. All rights reserved.</p>
|
||||
|
|
|
@ -38,7 +38,6 @@ Renders a menu for the given menu ID.
|
|||
{{- with .Children }}
|
||||
<ul>
|
||||
{{- partial "inline/menu/walk.html" (dict "page" $page "menuEntries" .) }}
|
||||
test
|
||||
</ul>
|
||||
{{- end }}
|
||||
</li>
|
||||
|
|