Is it too late to learn to code?

一位经济学专业出身的女性通过自学Ruby on Rails和iOS开发,成功转型为一名iOS开发者,并创建了一个激励女性健身的应用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Erin ParkerErin Parker, Founder Spitfire Athlete, iOS Engineer

9k upvotes by Francis ChenGaurav BahetiYue-Wing YauMaria Guryanova,(more)


It's never too late. So much can happen in a year, it can amaze you.

I majored in Economics. When I was about 23, I randomly decided to go to a Railsbridge Meetup, where you learn how to make a basic ruby on rails app in a day. I made a basic rails app and very much enjoyed it. A seed was planted that day.

Months later, I had an idea for a website I've always wanted to build. Although my idea was vague, in this website, I imagined it would inspire women to be kickass go-getters. I thought it would either be a career type of website, or one in the health and fitness space. And I definitely wanted to call it Spitfire. I strongly felt such a product was sorely needed and I felt like I had a pretty good perspective and vision to create it.

Although I hadn't committed to learning programming just yet, I would sketch out mocks like this:

16213130_DNTl.jpg


I would email these mocks to my friends and get their feedback. 

At the time, I was getting pretty hardcore into lifting weights and seeing a lot of results. I was also having a frustrating time finding high quality, trustworthy resources for women who lift weights and had this continuous nagging feeling that maybe I should actually do something about it. 

Finally, I decided to do it. Friends were asking me how I was getting in shape, how to lift weights, how to eat healthy. I decided to commit to learning ruby on rails and just building this out. 

I figured, if I learn to program, even if I fail, I would have at least failed building something that can help scale what I've learned to potentially millions of people. And that in itself, is a worthy pursuit. 

At the same time however, I decided failure was no longer an option. I wasn't going to let myself stop until I've built what I envision in my head Spitfire can truly be. I knew that if I just persisted through the pain (like an athlete), that the end result is going to be well worth the temporary pain.

I started teaching myself ruby on rails by voraciously consuming every free resource I could, like Learn Ruby the Hard Way, Try Ruby, Codecademy, Michael Hartl's book, Why's Poignant Guide to Ruby, the Rails Guides, and my absolute favorite, Railscasts.

I was relentless. If I didn't get something the first time, I didn't care. I would go through it again and again until it started to make sense. I would look for different explanations of the concept. I would ask my friends. When in coffee shops, if I was coding, and if the person sitting in front of me looked like they were an engineer based on the stickers on their laptop, I would kindly ask them if they could help (I have made so many friends this way, a few of them are still my really really good friends). 

I would go to lots of developer meet-ups, and particularly liked Women Who Code because of their "teach a new tutorial at each meetup" format and all of The Ruby Group meet-ups because it was easy to get help and unstuck.

I stuck with it for months and little by little "banged out" the ideas in my head. You can still see many of my early projects here:

http://spitfiredarkstar.herokuap...
http://spitfiredauntless.herokua...
http://spitfirehellcat.herokuapp... 
https://spitfireocelot.herokuapp...

I worked the most on this one:
http://spitfireathlete.herokuapp...

16213136_GVel.jpg


The site was quite feature-rich. It was pretty, had nice UX, and was a culmination of all the great ruby on rails stuff I had learned. Unfortunately though, no one was using it! 

It was exhilarating and discouraging at the same time. I felt like I had this great skill set...but that I was building stuff...that nobody wanted.

When I asked my friends why they weren't using it, I learned that what they really wanted was for me to "just tell them how to work out". And they wanted something that looked nice on their mobile phones, so they can train at the gym.

So I decided to change directions completely, learn jQuery Mobile, and I built this:

http://spitfirewarrior.herokuapp...

16213152_NA3P.jpg


What absolutely fascinated me about this was despite the fact that it was ugly and utterly simple - people actually used it! And they wanted more. And they wanted it as, gasp, a native iOS app. 

As a datapoint - it had been about 6 months since I started learning rails. 

I tried resisting the nagging realization that I might have to pick up iOS development if I wanted to take this further. I really tried getting jQuery Mobile to work but very quickly realized it's only great for prototyping (or very simple apps).

It was around April 2013. And I decided, you know what? I'm 24 but hell, I'm going to become an iOS developer. So what if I don't have a CS major? I have more drive and determination than most people. They may outsmart me, but I just never give up. I've already gone so far. Why stop now? #turtle

So I did the same thing. I voraciously went through every iOS resource I could find. I did all the exercises, the challenge exercises, and finished every book I could get my hands on from start to finish. I was very thankful to friends who would send me free PDF copies of nice O'Reilly books that were "expensive". 

I frequently attended the Women Who Code iOS meet-ups and benefited from the Big Nerd Ranch books on Obj-C and iOS, Ray Wenderlich's Tutorials, and Apple's Documentation. 

I built TONS of tiny little apps (that's how you learn)! I also made a promise to myself that I'm not going to ever think of any technology as "hard", because I think that's like a self-imposed ceiling on your learning. So I, quite fearlessly, ended up learning a bunch of stuff that scares away most iOS developers, that although I don't use it today, I realize it made me a much stronger developer, even though I had many long nights of "much stuckness".

Here is a photo of me giving a tech talk at a meet-up on how to make a custom Rails API and then send that data to your iPhone app using AFNetworking. 

16213201_qPvf.jpg


That was May 2013, age 24. I made myself give this talk...even though I had only *just* learned how to actually do what I was talking about. I felt very much like an "iOS imposter" and like I had just begun to get over the feeling of being a "rails imposter". 

Here is a screen shot of learning tableviews and transferring the concept of the Spitfire App to iOS, even though I ended up building everything again from scratch. I made this after 2 weeks of learning Obj-C.

16213207_af70.jpg


Months went by. Little by little I got better. Also, iOS is a very interface-heavy system and if you don't learn design, all your apps will look ugly. It's almost impossible to separate yourself from the front-end when in XCode. So I decided I should also probably learn design and Photoshop via the Hack Design curriculum. 

Photoshop was a lot easier to learn than programming, so eventually I made these really pretty mocks: 

16213216_lYyB.jpg



And eventually, around October 2013, I turned these mocks into the "Spitfire Athlete pre-Alpha" app. Here is a screen shot of the actual app running on my device: 

16213245_GzoZ.jpg


A couple months of struggling with Core Data and many passionate Test-Flight users asking for more features, I decided it was time to turn this crazy passion of mine into a start-up and I recruited an incredible co-founder, Nidhi Kulkarni, a razor sharp MIT CS grad who, like me, was also an athlete (she competed in D1 rowing while at MIT). 

With two technical, highly-driven ladies at the helm of Spitfire, I felt our productivity 10x. We started together around November 2013, I was nearing the end of age 24 (lol), and knew I was on the verge of something pretty exciting. 

We participated in the Code Path iOS Mobile Bootcamp together, a free bootcamp for professional-level iOS developers. We finished Spitfire Athlete alpha and at demo day (which was judged by VPs of Engineering from top mobile companies in Silicon Valley) we won "Best iOS App" and "Best Overall App". That was pretty cool, because I was definitely the only non-CS major in the entire class!

I turned 25 in January of 2014. In April of 2014 we launched to the app store and were featured on the home page in Best New Apps, and all over the Health and Fitness category. We now have tens of thousands of users and have gotten so much love mail, it makes me truly believe the journey so far has been worth it.

16213257_Nsa6.jpg



You can download the app from the App Store here: Spitfire Athlete

I decided to write this answer tonight because I recently had to renew my iOS Developer subscription. I thought, "Has it been a year? No way. Time goes by so fast." And then I remembered what it felt like, when I first started. 

I hope this answer inspires you and those who read it to learn how to program and make what you're passionate about become a reality, because the rewarding feeling of having built something that tens of thousands of people love is...indescribable.


翻译地址:http://blog.jobbole.com/78803/  共勉


转载于:https://my.oschina.net/lpe234/blog/479515

<think>我们正在解决Cursor中提交文件夹时出现"folder is too large to submit"的问题。根据错误信息,这通常是因为要提交的文件夹过大,超出了Cursor的处理限制。以下是一些可能的解决方法: 1. **精简文件夹内容**:删除不必要的文件,如日志文件、临时文件、大型二进制文件等。只保留源代码和必要的配置文件。 2. **分割文件夹**:如果可能,将大文件夹拆分成几个较小的子文件夹,然后分别提交。 3. **使用.gitignore**:如果提交与Git相关(例如在提交到GitHub时),确保通过.gitignore文件忽略不需要提交的大文件。 4. **压缩文件**:对于需要保留但不经常更改的大型文件,考虑压缩它们(例如使用zip或tar.gz),然后提交压缩文件。 5. **使用文件共享服务**:对于非常大的文件,考虑使用文件共享服务(如Google Drive、Dropbox等)共享,然后在项目中提供链接。 6. **检查Cursor设置**:查看Cursor是否有关于提交文件大小的设置,并尝试调整(如果有)。 7. **更新Cursor**:确保你使用的是最新版本的Cursor,因为新版本可能已经优化了文件提交的限制。 由于Cursor的具体限制可能因版本和配置而异,建议参考官方文档或社区支持获取更准确的信息。 根据引用[^1]中提到的,Cursor提供了便捷的功能来帮助开发者高效组织项目代码结构,因此合理规划文件存储位置和遵循文件命名规范也是避免此类问题的关键。 另外,引用[^2]提到Cursor是一款集成了先进人工智能技术的代码编辑与开发工具,它能够智能地理解开发者的需求。因此,如果问题持续存在,也可以尝试通过Cursor的AI功能寻求解决方案(例如,在Cursor中直接询问AI助手如何解决这个问题)。 如果上述方法都不能解决问题,可能需要考虑使用其他工具(如Git命令行)来提交大型文件夹,或者联系Cursor的技术支持。 §§相关问题§§ 1. Cursor对提交文件夹的大小限制是多少? 2. 如何配置Cursor以支持更大的文件夹提交? 3. 在Cursor中如何忽略特定文件或文件夹的提交? 4. 除了提交文件夹,Cursor还有哪些常见的文件操作问题?</think>### Cursor 提交文件夹过大无法提交的解决方法 当在 Cursor 提交文件夹时出现 **"folder is too large to submit"** 错误,通常是由于文件夹体积超出平台限制(默认限制为 **20MB**)。以下是系统化的解决方案: --- #### **1. 精简文件夹内容** - **删除冗余文件**:移除日志文件(`.log`)、临时文件(`.tmp`)、编译产物(`node_modules/`, `__pycache__/`, `.class`)等非必要文件。 - **忽略大文件类型**:检查是否有视频(`.mp4`)、图像(`.png`)或数据集(`.csv`)等大文件,必要时移至外部存储。 - **使用`.gitignore`**(若关联 Git):在根目录创建该文件,添加需忽略的目录/文件类型,例如: ``` # .gitignore 示例 node_modules/ *.log *.zip .DS_Store ``` --- #### **2. 分割提交** - **拆分文件夹**:将大文件夹拆分为多个子文件夹,分批提交。 - **增量提交**:仅提交修改过的文件(通过 Git 命令 `git add -u` 或 Cursor 的增量提交功能)。 --- #### **3. 压缩文件** - **压缩大文件**:使用工具(如 7-Zip)将大型二进制文件压缩为 `.zip` 或 `.tar.gz`,再提交压缩包。 - **文本文件优化**:对 JSON/XML 等文本文件进行压缩(移除空格/注释)。 --- #### **4. 调整 Cursor 设置** 1. 打开 Cursor 设置(`Ctrl + ,` 或 `Cmd + ,`)。 2. 搜索 **"File Size Limit"** 或 **"Upload Limit"**。 3. 若存在相关选项,尝试调高限制值(需注意服务器可能强制限制)。 --- #### **5. 使用外部存储** - **云存储链接**:将大文件上传至 Google Drive、Dropbox 或 GitHub Releases,在项目中以链接引用。 - **Git LFS**(Large File Storage):若项目托管在 GitHub/GitLab: 1. 安装 Git LFS:`git lfs install` 2. 跟踪大文件类型:`git lfs track "*.psd" "*.mp4"` 3. 提交更改(`.gitattributes` 文件会记录跟踪规则)。 --- #### **6. 命令行替代方案** 若 GUI 提交失败,可通过终端操作: ```bash # 进入项目目录 cd /path/to/project # 初始化 Git 仓库(若无) git init # 添加并提交文件(避开大文件) git add . --ignore-errors # 忽略错误 git commit -m "精简提交" git push origin main ``` --- ### 关键注意事项 1. **Cursor 限制**:免费版可能有严格上传限制,升级 Pro 版可能放宽限制[^2]。 2. **版本控制最佳实践**:避免将生成文件(如编译产物)纳入版本控制,优先提交源代码。 3. **性能影响**:过大的仓库会降低 Cursor 的 AI 辅助响应速度[^1]。 > **提示**:若问题持续,检查 Cursor 是否最新版本(`Help > Check for Updates`),或通过官方社区反馈问题[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值