Help coderanch get a
new server
by contributing to the fundraiser

Phelipe Maia

Greenhorn
+ Follow
since Jun 29, 2009
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
7
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Phelipe Maia

Mark T Thomas wrote:Ahh styling. A much contested topic in the React world right now. Basically the divide comes down to "use JS for styling" or "just use CSS". I think there are some incredibly cool things happening in this space, but don't feel like I need to take a side here. I guess in some ideal sense the CSS APIs and model etc. is so good it all happens there, but then you have the issue of encapsulation (making styling only apply to a given component). When CSS alone can do that in a super powerful way, a la, dare I say, web components, I think I'd be more comfortable saying "just use CSS". But there are super cool things that are happening w/ the "css in js" space. Check out https://emotion.sh/ especially!



Yeah, that's the big problem nowadays.. emotion.sh looks like styled-components. I will take a look on it.. Cheers
For you what is the best way to have shared components? I mean, you probably have one project that you place common stuff: modal, dropdowns, selectors, etc. And you probably use this project across other projects, changing only the styling and few other things. The point is, what is the best way to create those projects, being able to customise the shared components in an easy way and use in a lot of projects?

Best,
Hi,

I would like to know your opinion regarding styling. I've been working with projects with plain CSS, SCSS, others with styled-jsx or style-components. I know that for each project we have a proper solution, however I would like you know which one is the best solution for you. And how you organise your styling, I mean: in a variable in the same file of component, different file and import it to component, completely separate thing and never import to component, just add the CSS to the page.

Junilu Lacar wrote:Ideally, refactoring should be done often and in small increments and you should try to do it as soon as a failing test has been made to pass. The main motivation for refactoring is to eliminate duplication and to clarify intent. Simplification is also a good goal.

Of course, getting into the habit of refactoring is kind of like flossing your teeth: you know you should do it often but many people only do it once in a while or not at all.

The way you asked the question makes me think that you're not doing refactoring very often and when you do, they tend to be large efforts with a lot of code being affected. This almost makes me think that you're not actually refactoring your code but rather you're reworking it.



I agree but sometimes you don't have time to refactor the legacy code. It's hard to say that I will take this because before implement the feature the legacy code must be refactored.
My question is more philosophy than technical. heh. Well sometimes is hard to decide if we should start a refactor and once we've started is hard to decide when must stop. So how to know exactly the correct time to do that? Or always depends of the project and the moment (remembering that we're always with a lot of stuff to do, so the time is always crazy).

Runar Bjarnason wrote:Yes, I think you are wrong about that. Scala is a general-purpose programming language. And if you stick with FP, then building a "huge" system is exactly the same as building a small system. The approach scales very well.



Perfect! Thanks!
10 years ago

Runar Bjarnason wrote:It's my experience that FP actually reduces the "complexity curve". The space of potential solutions to a given problem is enormous, and FP really puts constraints on the solutions that are allowed. This simplifies your search through the solution space.

I also find that when developing functionally you do not need huge teams. A small team of programmers well versed in FP can be extraordinarily productive. You will do more with less code. That code is harder to write, to be sure, but it is easier to maintain, extend, and test.



I agree, but a team with programmers well versed will always be extraordinarily productive. I know the power of Scala and FP, but I can't realize a huge system written entirely in Scala. I wanna bet all in Scala, but I'm concern about build an ERP, for example, in Scala. The place that I see Scala is a language for high performance to be used in specific projects, or to implement some complex algorithms in a easier way. Do you know what I mean? Just let me know if I'm wrong about the main propose of Scala.
10 years ago

Runar Bjarnason wrote:Phelipe Maia:

In the book we try to give concrete examples of the benefits of functional programming. In short, those benefits are modularity and compositionality.

Modularity is the extent to which the parts of your programs can be separated and recombined in new ways. One practical benefit of this is code reuse. If it's easy to separate a part of your program out and reuse it in a different context, that enhances your productivity. Paul likes to say that "if you just eliminate all the duplicate code in your programs, you end up with functional programming". Another benefit of this is parallelization. If parts of your program can be cleanly separated, then those separate parts can be safely run in parallel. Testability is another. Again if you can isolate parts of your program, then they can be individually tested, which gives you confidence in the quality of your overall program.

Compositionality is the extent to which your program is composed of parts, each individually understandable, with clear rules of combining them. A compositional program can be understood just by looking at its parts and the rules of combination. Pure functions have this property because they are black boxes, and you can build larger black boxes just by plugging the output of one function into the input of another. The practical benefit here is that large systems can be assembled out of simple components.

A third and often overlooked benefit of FP is that it promotes programmer happiness. It is too easy to "create monsters", like you say, with other methodologies. Code that is hard to maintain makes your life as a programmer miserable. The accumulating technical debt creates friction, and makes it feel like you are trudging through a swamp whenever you need to change anything in the code. FP counteracts this. Code that is modular and compositional feels clean and is pleasant to work with, because it promotes clear separation of concerns (modularity), and safe recombination (compositionality). I have been programming for 28 years now, and I know how easy it is to create an unmaintainable mess with methodologies like OO. I think that if I hadn't come across FP, I would have stopped programming 10 years ago.



Really cool. Thanks for the explanation. I know that it's too easy to "create monsters" with all technologies and methodologies, but my concern is about the complexity curve in scala programming with FP. For example, would you recommend to develop an entire ERP in Scala with FP? I know that we can use Scala "as Java" and just take advantages of some API's. My question is more about the effort to create a huge team.
10 years ago
Well, my question is generic. It doesn't matter the language: scala, erlang, etc. I would like to know the benefits of using functional programming. Why should I use in my project in comparison to OO, for example. Other thing: I know that you can create a complex project in scala, really hard to maintain. So, how we can prevent the developers to create 'monsters'?

Thanks
10 years ago
You should use a JS library.. You probably will need more functions in JS and the libraries will help you to do an easier work. Take a look: http://jquery.com/

Damon Oehlman wrote:Hey Phelipe,

Thanks for the question. I think it is probably one of the best questions that anyone can ask before buying either this book, or any book on cross-platform (or device) mobile development.

It really comes down to the 80/20 rule (as so many things do). Essentially, 80% (and sometimes more, depending on what you are doing) of the code you write will work on any mobile device that comes with a WebKit browser, but the device OSes do require slightly different treatment for programming for the mobile web. Additionally, one of the things that I like to keep as an option is packaging an application for native distribution, which technologies like PhoneGap make possible.

I think that for now, an Android Web Apps book makes sense, but less so in a few years time when mobile web app programming has matured and starts to become the preferred approach - well, that's my prediction anyway.

The good news is that the majority of the books content is applicable to programming for other mobile device platforms that ship with WebKit browsers (iOS, WebOS, Blackberry Torch, some Nokia), but this still leaves a lot of devices that code samples in the book just won't work on. For example, Windows Phone7 as it ships with a browser roughly equivalent to IE7 (so no HTML5 or CSS3 support). As I said, this will almost certainly change in time, and when it does, then having a book titled "Pro Mobile Web Apps" (or similar) makes sense and will be able to provide content that someone buying the book would probably expect.

I hope this answers your question, but if not, I'll definitely try and provide more info.

Cheers,
Damon.



Perfect answer... Thank you so much!!!
13 years ago

Perry Hoekstra wrote:Define other devices? Android-based devices is a yes. iPhone, Windows Mobile, or Blackberry is a no.



Sorry, other devices = other o.s.. What is the particularity of android web app? Why i can't access from iPhone, Windows Mobile, or Blackberry? My question it's because if I develop a web app, doesn't matter the agent, I will access from anyone OS...

Thanks...
13 years ago
My question from a beginner android user... What is the difference between a development of android web app and other devices web app? For example: If I develop a web app for android I can access from other devices, can't I? So, Why a book specifically for android?
13 years ago
I read about the JavaScript API in HTML 5. So How does the test driven in HTML 5? Are there some frameworks to test? And how is the best way to test the animations in website?

Gregg Bolinger wrote:

Phelipe Maia wrote:I was thinking that in the case of native app I could build a local cache to work offline some basics operations. Is it possible?



Use the OS's built in SqlLite database. It's perfect for this scenario.



But If I build a native app, how does the communication could be made? I have to set up a webservice and my app should made requests against the webservice?

Tks...
13 years ago
iOS