Yep exactly! I know that it could be done via bash or a batch file. I just wanted to solve this usual problem with a simple project that also allows me to learn more about Scala since it's used at where I work.
462 karma · joined June 20, 2012
http://ace-subido.github.io/windows8-metro-modal
Another side project I'm currently in the process of designing:
Personal Problem: Me and my wife have some folders with so many random files. Too troublesome and time consuming maintaining it to be clean and organized. Pictures should be in a specific folder, installers in another one, etc. an example is the "Downloads Folder"
Solution: A small command-line utility that organizes a folder on where it runs from. This small command-line tool has only one parameter: a JSON file that contains "Rules" on what it will do on specific files. ex: .mp3's should be placed on a folder, .docs on another, etc. And so on and so forth. It could also come as an "installable" service/daemon that watches over folders. Still learning more about Scala, it's used in where I work, may write this command-line tool in that language for educational purposes.
Scaling equates to specialization, you specialize in a specific area of your stack because your startup has grown in that direction. In a very early stage, there's not much growth only a period of intense validation, so don't overthink about scale right now.
If you are using PostgreSQL, just stick with it. You can ship things faster and troubleshoot better with stuff you know. In terms of fetching data, you can design it in a way that you actually don't have to do any joins at all. Twitter still uses MySQL up until this very day, they've customized the core engine for their purposes. Point is: don't over-think about storage for now, no one knows right now where your startup will grow into :)
Build and design a pleasurably usable RESTful HTTP API Server with a matching client: in my experience this is very very helpful. At a very early stage, building an API server allows you to pivot relatively quickly. When you have a "proxy" for your database, it's practically developer-UX for fast changing business requirements, and it will avoid "database code hell" ie, random projects doing random things at your database.
Imagine you're building this huge web-app, but the users clearly want and need a mobile equivalent. What if the users want some sort of on-site installation for an enterprise version? Suddenly you're not a B2C startup and you'll be going on B2B.
An API server helps you do tons of things that enables you to ship applications faster and makes your startup very flexible since you can isolate and maintain this very large part of your product.
Maybe its due to the fact that I have no one I know there that has an account that could get me an invite :) been only a prospect for a very long time now.
If they've been working at it for a while, joining them is going to be a lot hard work. For one, it can be a warning sign, in the first place, their code will be hard to test. Dependencies will be out of this world, who knows where they put their business logic, random classes doing random things, random database session handling, god objects, and other elaborate hard-to-maintain hack stacks.
If you still want to join them, introduce testing to them by creating tests for one small part of their stack, it will easily show off the merits of testing:
- It's not just about putting something out there faster, it's also about failing business assumptions and the capability for your code to iterate/pivot quickly. Testing helps you in that aspect. Spend 10 minutes running the entire stack and tracing where a bug occurred, or just run your tests and find out what went wrong.
- The great thing about automated tests is that whenever I make huge changes in my code and the tests still run it means I can confidently say I didn't break anything at all. If I did, then I can easily know where and how, and I don't have to run through the entire app. I could easily isolate a single piece of my stack and test directly.
- Testing forces the team to write maintainable software.
- Another amazing meta-feature about tests is that, whenever you're debugging, it takes a huge chunk of business logic out from your cognition. You don't need to carry the extra cognitive load that 'x' part of your stack be able to 'y'.
Anyway, join them not for the sake of their code, join them if you just love what they're doing. You'll work through it.
Frankly they won't care about the libraries you used or how you coded the app, but at the same time freelancers should be technically sharp enough to write maintainable code with proper version control and automated tests, but more importantly, programmers should be skilled enough to propose proper solutions.
Example: Given a problem that can be resolved with an in-app chat solution, that chat solution shouldn't be based on polling a SQL database. I've seen one in production and what happened after it was released wasn't pretty.
Example: Given a problem that requires multiple POS machines with their own offline data to sync on a central database, a solution shouldn't be based on installing full SQL databases with purchased licenses armed with massive stored procedures moving data around. I've seen one in production. Maintaining, both financially and technically, costs so much for both the client and for their in-house dev team.
Technical skills should come naturally because freelancing is beyond code, it's about business development.
Freelancing/Consulting isn't just about coding/designing but its more on knowing what your client actually wants/needs, educating them about your proposed solution, delivering that need, knowing how to deliver that need through proper communication, and making them go through a process with a tight feedback loop that is both pleasurable, emotionally and on paper, that would make them go back to you and/or refer you to others.
Most software out there are just CRUD apps, or as I would like to put it: glorified excel sheets. Other than delivering a standard website with Wordpress/Drupal as your solution, custom software and building on top of other poorly written custom software from previous developers will be your toughest challenge if your technical skills are still being sharpened. But if you feel your technical skills are sharp enough, you can already go out there and do something on the side :)
First, logistically speaking, transport, supply and communication lines in the Philippines are hard to establish because we're an archipelago of 7,000+ islands. The unique geography makes it hard for mass evacuations. Go to high areas, suffer landslides and wind damage, stay low, storm surges wipe you out.
I don't know much about the Indian typhoon season, but the Pacific typhoon season, since the 90's on average, starts at January-March and ends at November-December: it doesn't stop. Fortunately we've had good years, such as the 1998 storm season, the first storm system formed started in July at that time. On average, most of the Pacific storm systems hit us every 3 weeks, there are certain months where parts of the country get hit by a typhoon every other week. So almost all resources are poured into constantly getting supply lines and shelters re-established.
Given this, we Filipinos have been taught, even the children, to consider typhoons to be normal and to have their distinct personalities to look out for. I remember back in 2009 that we took a direct hit with Typhoon Ketsana (Ondoy). It wasn't expected to deal that much damage since Hurricane strength is generally associated with wind speed, the measured wind speed wasn't that high. What we didn't we know was that it brought 454.9 mm rainfall in the Metropolis, flooding rural areas in our capital region as high as 4-6meters. Uncertainty is high, resources are low, the islands of Samar and Leyte got hit badly: the eyewall brought in the surge from the east and when the storm passed by, the tail surged the sea inward from the west.
Also, it's hard to get good data. Info and news from the media and government are unorganized, each have their own databases, and not to mention, their own agendas to look good.
Majority of Filipinos consider the lack of financial resources as the biggest factor due to politics and corruption. As mentioned in the comments above, the mayor of the city of Dumaguete can only set aside something like $9,000 USD. Not a lot of resources, considering that's just enough to buy a car here in the Philippines.
The lack of resources and wealth, the difficulty of re-establishing supply lines sets up an environment for such casualties despite preparations.
Currently working on a command-line client that can organize all photos, videos, pdfs, zip files, installers at their proper places.
Based on experience, you can deploy 'something' out there and build that 'something' really fast with Grails. GORM instantly takes care of persisting to DB with minimal effort, there's not much to configure. If you're planning to just create an API Server, the latest Grails 2.3.x releases have specifically made that easier too.
Can't say anything for Play since I haven't used that, but if you face growth problems with your Grails project (scaling), just piece off the heavy parts and create separate services written in Scala. First hand experience, Finagle is a good choice for this. You can easily be productive and quickly create services with this RPC system.
Conclusion: In my opinion, your best option for creating an MVP/Prototype is Grails.
The point I was making was that sameness is a market effect, not a technological one. If everyone in the world started craving for Google Glass tomorrow and nothing else, everything in the world of design or systems architecture would trend in that direction in a reasonable amount of time. Trend in a sense wherein it is easily produced, etc. and other factors.
Linus started Linux at 21, Martin Odersky started designing Scala at around 46, likewise James Gosling fathered Java at around 39, Joel Spolsky founded Fog Creek around 35, Jack Dorsey founded Twitter around 30.
The measurement of time is a man-made system, it does not matter if you're 20 or 65. Comparing yourself with amazing people and their achievements and age will gain you nothing but discontent.
I'm 26, I'm excited with what I'm living with right now and what I'll be taking on in the years to come.
Based on your recent post about your specific target market (Wall St.), talk to them. Based on your recent post it seems that you're doing high-volume B2B transactions. If you ask HN about how much we would pay for that, you would get lesser value from our answers since we would compare your hardware offering to EC2 instances, which I guess, isn't the type of market you're after.
Talk to the Wall St. guys you're targeting, call them up or send them an SMS, grab 30 minutes of their time and treat them out for coffee. Don't ask them how much they'd pay for it, instead, spark up a conversation about what they're currently using and if you're lucky they'll tell you how much they're spending for it. Watch out for keywords on what they value. You can charge more by offering what they value.
If they value SLA's, high-level support and a specific amount of latency, charge based on that.
After talking with them, tell them and their IT team to subscribe to your mailing list which will not spam them, but educate them about handling financial data coupled with your hardware.
Gain their trust from your expertise, close sales from that mailing list once you launch.
Usual corporate sites want to tell everything about themselves. That's why they opt to display it in such fashion: long prose that don't make sense. That's why it subconsciously looks 'ugly' because you don't even know what you're looking at. The content of corporate websites aren't intended for capturing people, majority of corporate websites are intended to inform - think of it like a company brochure.
Decision makers that want this "web presence" are 1) not educated enough to realize the difference between print and digital media, and 2) not educated enough about the cost of web development. That's why corporate websites can be likened to a huge company brochure that doesn't make sense when translated into the web. To top it off with the already mentioned comments about "approvals", instead of working with designers to make sure the website looks highly presentable and understandable, designers are constantly overridden with the 'preferences' of these decision makers.
In a startup, things are different. People work closely together to bring the organization into a higher level. The key decision makers know that they only serve as a visionary to a team of people, and they know they have to work closely with highly talented people in order to bring the organization to life. This setup results into a deeper level of communication that allows the designers and decision-makers to move as one into knowing what content to write and how the website is designed around that content in order for the readers to flow through the website.
The prose on the website turns out to be cleaner, and much clearer. One goal, one message. Pages meant to inform and pages meant to capture visitors are segregated appropriately, visitors get captured and get informed. The "look better" part is just a byproduct of that kind of unity found in a start-up, it isn't even a critical goal.
The stress may come from the crying of your child. My older brother and his wife had the same stress problems (don't know about the resentment part), but mainly due to the fact that they couldn't understand what the baby wants from his crying. The frustration of not being able to appease that cry can in fact produce great stress, try the Baby Listener's advice. It worked for my brother and his wife. Search for videos about it.
As a visitor, there's a lack of focus of what you want me to do here.
The "Find the perfect gift" wizard seems to be overpowered by that toolbar. Do you want me to sign up? Do I need to know "About"? Do you want me to "Add a gift"? What am I suppose to do? Search? Do I really want to "search" or "browse"? How does it "work"? Is it the main thing you offer? If it's the main thing, I guess it would do best to emphasize it by putting it as a big search bar on the center.
1) Rethink that toolbar, go easy on it. Just a tip: It'd do best to put the "About" section at the footer.
2) Focus on what you want your visitor to accomplish. Emphasize on that, remove focus on everything else. Make it easy on them, consumer-type visitors have short attention spans. Respect that 10 second hold you have on them by making it easy to expose your main feature to them.
3) All advice are just 'words' unless it's tested. You can hold to the truth that any advice given are currently considered worse than your current assumption, given that your assumption is on the server and being tested by people while advice is just on a persons head.
When you're thinking about other things, it means what you're about to do is so much of a chore to you that you subconsciously procrastinate and despise doing it. Remember that what you're working on is something you love; you'll soon find out that everything else doesn't matter. Love isn't a feeling, it's a decision to commit because you found value no one else can't seem to see.
It's clear that the most productive people are people in love in what they do. They find joy and value even in their smallest chores/tasks. They don't need to "minimize distractions" or use "software program that blocks any time-wasting internet site", it's natural for them to have a distaste for other things except on what's currently right in-front of them.
The practical task lists or methods on "how to focus" are easy as pie, there's a lot of content tackling, although looking for something you love working on or reminding yourself that you should love what you're doing - that's something only you can answer.
1) We make "progress reports" by updating our own tasks assigned to us within the Sprint. The "boss/manager" just takes a peek at burn-down and other charts. For more details he just takes a peek at the latest updates on the comments.
2) Daily, I take 5 minutes to write a simple comment on the task assigned to me. Daily updates are better than weekly ones, weekly comments and paragraph type progress reports tend to be too abstract for it to have actual meaning. Sometimes paragraph-type reports are too verbose for a decision maker to make decisions upon. We let the charts speak for themselves in terms of weekly overviews.
If a software development team uses docs and text files to submit reports, 1) the development process is still in its infancy or 2) no budget is alotted for project management tools because quality software development is not a priority for the company.
I saw family businesses of friends lose people who've worked with them for years without them telling them anything, maybe because those people experienced what you're experiencing. They would always tell me this bit: "we wish they approached us and talked, or at least some heads up that they got a new job".
You've hit a wall in your career, you're relying on spoken word from men instead of signed contracts - which is quite dangerous for your career path. Unless you're in it to actually develop and grow a long and deep relationship with the people, not the company, talk with them.
They've talked you into this position and you didn't sign anything, I think it's fitting to also talk to them as well, just tread tactfully. 10 years and that new "role" is enough to assume that they've come to embrace you as a key person in their father/son company and they would, hopefully, professionally hear you out.
You'll need to include them into your thought process. If you were to stop portions of the job on your own, they'll be quite surprised and it'll put you in really bad light. I mean, you've been working cleanly for 10 years and you suddenly changed after those months into the "new role", then they'll know something is amiss.
Also note that if you look for another job without telling them anything, it also puts you in a bad light. If they've slowly come to embrace you as family during those 10 years, they'll want to know why you're leaving.
Totally, agree
> I don't really understand what 'rely on a community' means here. Who does not depend on open source software?
I'm sure you know this - that's how a huge chunk of non-tech people view anything labelled with "open-source", they all view it as "unreliable" or "geeky". By how I constructed my sentence it seems I'm saying this from my perspective, but we're like minded in that aspect: everyone depends on open source software one way or another.
I'm just assuming that's how his client thinks.
I'm assuming the decision maker for his client is one of those 'guys' who's outside the tech bubble, and probably worse: they don't listen to engineers. I mean, if OP has already built a nice prototype on Backbone and it's all good why would they go towards ExtJS? Backbone is widely used and constantly worked upon, if his client is well aware of the software development industry they wouldn't just dismiss the prototype and go towards something with 5-digit contracts.
Again I'm just assuming the worst case scenario about OP's client by trying to understand the situation from what he said about their decisions.
> I'm also a co-founder and technical guy, I assure you spending money is always the last thing any company wants to do.
I'm also sure you know this: any hard-headed, non-tech decision maker outside the software industry who is very desperate would throw a lot of money for a problem to go away.
Decisions like that don't come from developers, they come from the typical 'business guy'. Generally speaking bleeding-edge frameworks don't bode that well for any business guy. If a problem arises and a developer gets stuck, a developer just googles it and looks for ways to tinker with it - in the eyes of the 'business guy' they'd opt to throw money at the problem for it to go away, no time should spent troubleshooting or googling.
To sum it up: your client can't rely on a community of people that supports things only in their spare time. Thus by gaining comfort and trust from buying ExtJS contracts (https://www.sencha.com/store/extjs/) - whenever something goes wrong, your client's dev team gets stuck or needs training they can choke the hell out of Sencha for it.
Just let them go through with ExtJS. If the decision maker has consulted his devs long enough, it's a better decision. Being in one page and getting their things done quickly is far better than taking too much time learning things and contemplating on what framework to use.
Given 5 years time and a few hundred million dollars, I would heavily support them. As a software developer I don't know much about robotics in general but I think a simple step on moving forward is if there was a way to create a friendly abstraction on top of the quadcopters.
If you're trying to study concepts, it's a different case. You study the concepts, not specific technologies.
An example would be MVC. There's a lot of MVC frameworks that's out there. If you want to pickup on MVC, just choose among the MVC frameworks - Groovy/Grails, C#/ASP.MVC, PHP/CakePHP, Ruby/Rails, etc. etc. again, stay away from hype and language/framework vs. language/framework debates. If you pick one you're comfortable with, the concepts transcend language and time. If your career moves you on to another language, you'll find MVC is 'almost' the same save for minor differences that is brought upon by the languages themselves.
Especially applicable for the number of JS MVC Frameworks popping up every 3 or so months.
Ruby itself is a great language, and that's what it is at the end of the day - it's just a language. What matters more is the community gather under it. As with any community, there are members that tend to be immature and arrogant which may reflect to anyone as a representation of the entire Ruby community as whole. Worse comes to worst, these "few members" can affect the culture of the community especially for new users of the language, turning the community and the language somewhat "cultish".
Check out http://e27.sg/
If you happen to drop by in the Philippines for your vacations, drop by http://webgeek.ph/
http://represent.ph might be helpful, it's a map of start-up technology companies in the Philippines.
If you're thinking it'll scale, it's much better to deal with scaling problems in a stack you're familiar with. So for your server stack I'd suggest these:
- PaaS: AppHarbor or Azure Cloud Services. You can easily scale up with them by a few clicks.
- Server-side: Seeing as you chose NodeJS, I assume you're going to use the stack's asynchronous nature, might I suggest looking up SignalR (http://www.hanselman.com/blog/AsynchronousScalableWebApplica...)
- ORM Layer: NHibernate
- DB: MySQL
Again, I'm not saying not to use NodeJS because I'm some sort of Microsoft Fanboy, I'm just giving suggestions based on how much "better" you can push out your project "quicker", and maintain/support it with lesser friction.
When you keep jumping jobs, it means you haven't figured out what you want to dedicate yourself to because you easily get distracted by 'new and interesting' things. Truthfully, when anyone is really passionate about their job, they never see it as 'work', they naturally tend to stick to it for the next 3 or more years of their life - and those people are the ones who tend to naturally create "interesting" things (ex: 10gen, 37signals, Redis, NodeJS etc.)